From owner-freebsd-stable Tue Dec 18 11:34:18 2001 Delivered-To: freebsd-stable@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id A194C37B417 for ; Tue, 18 Dec 2001 11:34:08 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fBIJeaO01489; Tue, 18 Dec 2001 11:40:37 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112181940.fBIJeaO01489@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Adrian Steinmann Cc: stable@freebsd.org Subject: Re: Waaaarg, we just blew out the kernel again.. In-reply-to: Your message of "Tue, 18 Dec 2001 12:33:14 +0100." <200112181133.MAA11130@marabu.marabu.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Dec 2001 11:40:36 -0800 From: Mike Smith Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > 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