[OLPC-devel] Re: Not so good news (Was: good news)
stepan at coresystems.de
Sat Aug 5 06:20:47 EDT 2006
* 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
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de • http://www.coresystems.de/
More information about the Devel