[uClinux-dev] [PATCH] mtd: clean up uclinux.c map driver

Mike Frysinger vapier.adi at gmail.com
Wed May 16 12:23:44 EDT 2012


On Wed, May 16, 2012 at 7:49 AM, Greg Ungerer <gerg at snapgear.com> wrote:
> On 05/16/2012 03:02 PM, Mike Frysinger wrote:
>>
>> On Tue, May 15, 2012 at 10:55 PM, Greg Ungerer<gerg at snapgear.com>  wrote:
>>>
>>> On 16/05/12 12:42, Mike Frysinger wrote:
>>>>
>>>> On Tue, May 15, 2012 at 8:45 PM, Greg Ungerer<gerg at snapgear.com>
>>>>  Ã¡wrote:
>>>>>
>>>>> On 16/05/12 01:57, Mike Frysinger wrote:
>>>>>>
>>>>>> On Tue, May 15, 2012 at 12:08 AM,<gerg at snapgear.com>  Ã¡â”œÃ­wrote:
>>>>>>
>>>>>>> . make the struct uclinux_ram_map static
>>>>>>
>>>>>>
>>>>>> NAK: this breaks Blackfin systems. áwe specifically don't want
>>>>>> this to
>>>>>>
>>>>>> be static.
>>>>>> it should probably get a comment added above it saying as much.
>>>>>
>>>>>
>>>>> A comment won't fix the sparse warning. You need a proper declaration.
>>>>
>>>>
>>>> perhaps, but marking it static to fix a warning that people rarely see
>>>> whilst simultaneously knowingly breaking an arch doesn't sound like
>>>> the correct trade off.
>>>
>>>
>>> I agree, of course. It wasn't done to knowingly break an arch. But
>>> the sparse warning can be fixed with a proper declaration, that
>>> would avoid you having a local extern for it in
>>> arch/blackfin/kernel/setup.c as well. Cleaner all round.
>>
>>
>> i thought you were going for merging anyways.
>>
>> where would you suggest adding such a decl ?  there isn't an existing
>> one i can see that this would fit into.  might have to create a new
>> one just for this ?
>
>
> No I don't see any existing place that makes any sense. I guess it
> could be something like a new file include/linux/mtd/uclinux.h.
>
> But it looks like Artem is ok with just reverting it to not be static.
> I am happy to leave it that way if you are.

would be good to add a comment so someone doesn't clean this up again.
 i can post a patch for that though.

i know the current struct behavior is ugly, but it's cleaner than
previous iterations ;)
-mike



More information about the uClinux-dev mailing list