> > Hmm.. I just tried bzip2ing vmlinux.. Not a big improvement.
>
> Big is a relative term. If you are 20K short of including something you want
> then 60K extra is big. Also look at what you save for the compressed root
> file system not just the kernel image.
You should look more closely on what you _real_ win, then you'll see its not
worth the work.
- You have to use the smallest buffersize for bzip2 (option -1), which
will nevertheless need a buffer of 100K. Hence, forget it for zImages.
^^^^^^^^^^^^^^^^^^^^^
For a bzImage (which anyway is far away from reaching its limits),
I tested it and got these sizes for the 'tmppiggy' after compression:
477424 Dec 15 15:38 /tmp/3871piggy.bz2 (bzip2 -9)
497139 Dec 15 15:39 /tmp/3871piggy.bz2 (bzip2 -1)
508444 Dec 15 15:35 /tmp/3871piggy.gz (gzip -9)
Seeing it? You win 10(30)K but have to supply a buffer of 100(900)K.
- Currently for zImages, as decompression proceeds, the memory
holding the zImage itself is used as buffer. With bzip2 you can't do
such tricks, because you need the buffer as _one_ big piece.
- You have to rewrite (and test!!!) linux/lib/inflate.c
( not sure this is a stabilizing factor )
- you'll force all people, who want to compile the kernel to have
bzip2 handy (currently not the case)
- ... and (as was stated already) bzip2'ed decompression will be
way to slow for a booting process.
Hans
<lermen@fgan.de>