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

[Stefan Reinauer]

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.

Stefan

-- 
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/