[uClibc] Buildroot & inittar patch

Thomas Cameron tom at drdabbles.us
Wed Dec 15 15:22:53 UTC 2004


> -----Original Message-----
> From: uclibc-bounces at uclibc.org 
> [mailto:uclibc-bounces at uclibc.org] On Behalf Of Thomas Lundquist
> Sent: Wednesday, December 15, 2004 3:40 AM
> To: uclibc at uclibc.org
> Subject: Re: [uClibc] Buildroot & inittar patch
> 

[SNIP]

> which sounds like a really good thing.
> 
> but can this be combined with replacing gzip with bzip2? which will
> shave off a bit more on the storage media.
> 
> (I have seen a few bzip patches for the kernel but none has seemed
> stable and good enough to me but it's been a while)
> 

Yes, there are patches around to add bzip2 capabilities to the kernel. Some
are _horrible_, others are only hideous. I have not seen one I personally
felt comfortable placing into a production unit, and from what I remember I
had to do quite a bit of hacking to make things work.

Having said that, this patch
(http://www.escape.de/users/outback/linux/patches/bzip2-i386-2.4.26-zip1.bz2
) and this patch
(http://www.escape.de/users/outback/linux/patches/patch-2.4.26-bz2-inittar.b
z2) will add the functionality to the 2.4.26 kernel. The author of the
inittar patch has created both of these patches to fix some fuzz when
applying, and to make things play nice together. I have not tried these
particular patches, but I may in the near future.

It has been my experience that the increase in code size to add bzip2
compression, or to even replace gzip with bzip2, far outweighs any gains you
will see from compressing your root fs image. Then again, if you're creating
livecd's, or complressing root images that are not destined for an embedded
system, you may see just the opposite.

Certainly keep us all posted on your findings. It's always nice to squeeze
an extra few bites out of a system. :-)

Good Luck,
Tom

--
Tom Cameron
tom<at>drdabbles<dot>us  





More information about the uClibc mailing list