[OLPC-devel] Re: Not so good news (Was: good news)

[Eric W. Biederman]

Stefan Reinauer <stepan at coresystems.de> writes:

> Hi Eric,
>
> * Eric W. Biederman <ebiederm at xmission.com> [060805 10:13]:
>> If there is truly a gain to doing compression like this?  nrv2b is a
>> decent compressor but I think for large sizes gzip is probably the
>> better compressor.  I believe I have a formula for a compressor of
>> arbitrary ELF executables if anyone is interested.  I have never seen
>> the value in putting the decompressor in LinuxBIOS for this stuff.
>
> Not "for this stuff". The situation is more complex at the moment

>
> - LinuxBIOS comes with a decompressor anyways (when you use
>   CONFIG_COMPRESS) which could be reused.
>
>   Currently the same source is used except some minor glitches,
>   but the goal is to use the same code for all stages. We can
>   use the same algorithm and same decompressor entity to decompress
>   a vga bios, vsa binaries, (everything except the decompressor of)
>   linuxbios_ram and now the payload.
>  
> - The payloads (except Linux) don't necessarily come with a compressor
>   I found myself planning to add a compressor to both OpenBIOS and FILO
>   so it's easily possible again to pack them in 256k flashes with
>   LinuxBIOS Fallback/Normal and all possible features. The way etherboot 
>   handles this is just crap, and implementing a more complex solution
>   like linux does makes absolutely no sense as we have one decompressor
>   in flash already.
>
>   If nrv2b is not good enough, lets replace it by bzip2, lzma or
>   whatever we find useful. But self extracting executables are a 
>   leftover fad from DOS times, when it was not easily possible to
>   plug in new compression algorithms to work transparently at any
>   stage.

As long as it is buildrom or some LinuxBIOS that is doing both
the compression and the decompression I guess I don't have a problem.
The only downside is that it means in general you have to flash all of
LinuxBIOS together and can't flash the payload independently.  Which
isn't a huge loss.

Anyway we still have not addressed the practical question of why
we are getting a truncated rom size and so this technique is not working.

Eric