From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerlando Falauto Date: Mon, 12 Dec 2011 14:38:24 +0100 Subject: [U-Boot] [PATCH v2 1/3] env: unify logic to check and apply changes In-Reply-To: <20111212121859.E621F183AA35@gemini.denx.de> References: <1321634955-5561-1-git-send-email-gerlando.falauto@keymile.com><1323264605-13541-2-git-send-email-gerlando.falauto@keymile.com> <4EE5CA38.6090807@keymile.com> <20111212121859.E621F183AA35@gemini.denx.de> Message-ID: <4EE603D0.5010109@keymile.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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