BTW, if you want super tiny kernels, check out Microsoft's (unpatented, surprisingly well documented) LZX compression format. It's specifically designed to compress x86 machine code, so it beats out all the general-purpose compression algorithms if the payload is a binary. I think libmspack has an LGPL'ed LZX compressor/decompressor.
- a
ebiederman@lnxi.com (Eric W. Biederman) writes:
Richard Smith rsmith@bitworks.com writes:
Has anyone tried this to see how small it compiles down to?
I just looked. With everything turned off I have built a 220K kernel. 371K uncompressed but that doesn't count.
It looks like there is light at the end of the tunnel.
Eric _______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Adam Megacz adam@megacz.com writes:
BTW, if you want super tiny kernels, check out Microsoft's (unpatented, surprisingly well documented) LZX compression format. It's specifically designed to compress x86 machine code, so it beats out all the general-purpose compression algorithms if the payload is a binary. I think libmspack has an LGPL'ed LZX compressor/decompressor.
It looks like it is present in libmspack. What kind of compression ration do you get with LZX? Unless it is noticeably greater than 2:1 the major gains are not to be had with compression. Currently I use a stripped down version of UPX when I really want a small self extracting binary. The nrv2b algorithm has an absolutely tiny 100 byte or so decompressor.
For the kernel the decompressor is 8K. Which is significant but it is again not a major bottle neck.
The target is to see how useful a linux kernel that we can put into 384K. For use as a boot loader by LinuxBIOS.
Eric
-
Adam Megacz -
ebiederman＠lnxi.com