On Thu, 25 Feb 2010, Hector Martin wrote:

Compilers are getting smarter, and code relying on old assumptions that
may no longer be true (because compilers optimize better or do things
differently) is precisely that which is most liable to break. The only
way you can properly guarantee things will work is by sticking to actual
standards and doing what the compiler expects you to do. Moving around
text/rodata without moving around bss/(maybe data) isn't something
allowed by the compiler. Sure, you can hack around it like we're doing
here, but you're relying on your hacks correctly preventing the compiler
from doing something valid yet which breaks your assumptions.

Sure.  And so far we've used a naive hack with -Dstatic.  Russell's 
patch is now removing the hack and making sure the restrictions we count 
on are respected wrt .data section.  If we need to ensure no static .bss 
variable are used we might just add this in the Makefile:

	[ "$(nm compressed/vmlinux | grep " b ")" != "" ]

Well, if you're into speed anyway, caring about the actual kernel size
is desirable because it avoids a totally useless copy when the zImage is
loaded into RAM somewhere near the end of where the kernel would be. The
guesstimate in the code will think it'll overlap and move things around
unnecessarily. Worse, if the kernel ends up being highly compressible
for whatever reason, it could overflow the 4x guesstimate and make the
whole compressed loader fail again if it happens to be around there.

Those are valid points, and rather orthogonal to the ROMable 
decompressor issue.  Better not to mix them together.

And I vaguely remember trying to do just that a couple years ago: 
getting hold of the decompressed kernel size and feeding that into the 
decompressor code.  I somehow didn't come up with a satisfactory 
solution and never revisited it since.

But this discussion is rather pointless because at this stage I highly
doubt Russell is going to change his mind.

If you produce a patch for the above, and it is clean and portable, then 
I suspect he would just merge it.  Only at that point we could 
reconsider the ROMable decompressor issue.


Nicolas