Date: Tue, 18 Dec 2001 11:40:36 -0800 From: Mike Smith <msmith@freebsd.org> To: Adrian Steinmann <ast@marabu.ch> Cc: stable@freebsd.org Subject: Re: Waaaarg, we just blew out the kernel again.. Message-ID: <200112181940.fBIJeaO01489@mass.dis.org> In-Reply-To: Your message of "Tue, 18 Dec 2001 12:33:14 %2B0100." <200112181133.MAA11130@marabu.marabu.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
> matusita@jp.FreeBSD.org wrote:
> If we can compress kernel image by bzip2(1),
>
> -r-xr-xr-x 1 root wheel 1343299 Dec 17 07:53 kernel.gz*
> -r-xr-xr-x 1 root wheel 1292744 Dec 17 07:53 kernel.bz2*
>
> we get additional 50kbytes spaces. It seems that loader does
> understand bzip2ed kernel; anybody tried it with 4-stable ?
>
> I've tried this just recentlz by defining LOADER_BZIP2_SUPPORT=YES
> in, say, WORLD_FLAGS (cvsup of Dec 15 Noon MET), these are the
> kgzip-ed loader sizes:
Whoops, I forgot that this was already done.
>
> -rwxr-xr-x 1 root wheel - 90919 Dec 17 02:14 loader # LOADER_BZIP2_SUPPORT
> =YES
> -rwxr-xr-x 1 root wheel - 81927 Dec 18 05:01 loader # without
>
> Note that this has the effect that the loader gets even bigger since
> it now supports both GZIP and BZIP, and that support is not made
> use of when "making release". One would have to burn the bridge
> completely and define LOADER_NO_GZIP_SUPPORT and then change line
> 958 (doMFSKERN target) in /usr/src/release/Makefile to do 'bzip2
> -1' instead of gzip. Then maybe the loader would stay small and
> 'make release' would create bzip-ed kernels. Alas, I haven't tried
> this because it just takes so long to test this stuff, and I have
> a doubt:
Testing it doesn't actually take very long; you can build the loader by
itself and just mount/unmount the kernel floppy image to play with gzip
vs. bzip2.
> LOADER_NO_GZIP_SUPPORT might not work because how would the kgzip-ed
> loader ungzip itself if it doesn't support it anymore? Is there a way
> to "kbzip2" an executable?
The kgzip support isn't dependant on the loader's internal compression
support; it's a standalone module.
Realistically, we should just standardise on a single (de)compression
engine for the loader and use it; whether it's gzip or bzip doesn't
matter all that much, except that gzip is part of the system via libz,
and bzip isn't.
> The way to go which has a brighter future is indeed to modularize
> more drivers and avoid GENERIC bloat.
Amen. 8)
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200112181940.fBIJeaO01489>