On Thu, 25 Feb 2010, Hector Martin wrote:

Nicolas Pitre wrote:

quoted

On Thu, 25 Feb 2010, Hector Martin wrote:

quoted

If you can programmatically ensure that the decompressors do not use
anything but GOT entries to access data, that's certainly a better
solution than what we have now (I don't mean actually "fixing" them as
in -Dstatic=, just something that makes the build fail if this is not
the case so someone else can go and make the required changes). Maybe
building the object and then grepping the relocations for offenders, or
something like that.

Russell made a patch which simply ends up discarding .data section.

You still have the issue of the .bss section. Though I must admit this
would be rare, a decompressor using the .bss section would still cause
silent breakage.

What breakage?  We do use the .bss right now.  But .bss can be fixed to 
some absolute address in RAM with no further handling besides clearing 

I found the following at the top of arch/arm/boot/compressed/misc.c:

 * Nicolas Pitre [off-list ref]  1999/04/14 :
 *  For this code to run directly from Flash, all constant variables must
 *  be marked with 'const' and all other variables initialized at run-time
 *  only.  This way all non constant variables will end up in the bss segment,
 *  which should point to addresses in RAM and cleared to 0 on start.
 *  This allows for a much quicker boot time.

And I'm still not convinced that compiler behavior is defined such 
that this cannot break in the future.

Seems to me that we're relying on compiler conventions that have been 
around for decades already.  What do you expect to break?

quoted

You are still copying the actual decompressor code which is less optimal 
than what we already have.  The current solution, as I explained 
already, involves _zero_ copying.

The overhead of copying the decompressor is negligible. We're talking
somewhere along the lines of 0.1% of the time spent inside the
decompressor, worst case.

Possible.  And granted this whole scheme was elaborated in 1999 when 
CPUs were much slower and the kernel much smaller relative to the 
decompressor, etc.  But again that "just works" already, without the 
copy overhead, and the code needed to make the copy (I know it's only 4 
asm instructions), and the complexity needed to care about the actual 
decompressed kernel size, etc. etc.


Nicolas