[U-Boot] [PATCH v2 1/3] env: unify logic to check and apply changes

[Gerlando Falauto <gerlando.falauto@keymile.com>]

On 12/12/2011 01:18 PM, Wolfgang Denk wrote:
> Dear Gerlando Falauto,
>
>> I think it's easier to read it the original way, and it should not make
>> any difference as far as code size is concerned.
>
> The Coding Style makes an explicit exception regarding the line length
> for user visible strings:
>
>   83 Statements longer than 80 columns will be broken into sensible chunks, unless
>   84 exceeding 80 columns significantly increases readability and does not hide
>   85 information. Descendants are always substantially shorter than the parent and
>   86 are placed substantially to the right. The same applies to function headers
>   87 with a long argument list. However, never break user-visible strings such as
>   88 printk messages, because that breaks the ability to grep for them.

I don't understand: why are you quoting this here and now? The chunk we 
are referring to doesn't change a bit about the printable string.

>>> himport_r() is getting a bit overloaded,
>>
>> Actually, I believe it makes no longer sense to have it called "_r", as
>> it was the original reference to the function being recursively
>> calleable (i.e. reentrant) as opposed to other versions which were not.
>
> Has this changed?

Of course it hasn't. But I don't see any point in keeping this notation 
anyway.

>>> Also, for me this patch adds 500 bytes. I wonder if more of the code
>>> could made optional?
>>
>> Frankly, I'm surprised to hear this adds that much overhead.
>> Actually, I can't see this increase in code size as you mention.
>> What architecture are you referring to?
>> In my workspace (ppc_6xx) u-boot.bin and a stripped u-boot ELF file are
>> surprisingly unchanged in size, even with debug #defined!
>
> Don't look at file size. Use the "size" command and compare code /
> data / bss sizes.

Yep, sorry, I'll look into that to see what part is mostly reponsible 
for this.

Best,
Gerlando