Date: Wed, 10 Dec 2003 16:25:36 +0600 From: Alexey Dokuchaev <danfe@nsu.ru> To: Sean Chittenden <sean@chittenden.org> Cc: cvs-src@freebsd.org Subject: Re: cvs commit: src/sys/i386/conf GENERIC src/sys/alpha/conf GENERIC src/sys/sparc64/conf GENERIC src/sys/amd64/conf GENERIC src/sys/pc98/conf GENERIC Message-ID: <20031210102535.GA3135@regency.nsu.ru> In-Reply-To: <20031209070020.GC59494@perrin.nxad.com> References: <200312072352.hB7Nqsw6011333@repoman.freebsd.org> <20031208190305.GA956@cirb503493.alcatel.com.au> <20031209070020.GC59494@perrin.nxad.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 08, 2003 at 11:00:20PM -0800, Sean Chittenden wrote: > > >scottl 2003/12/07 15:52:54 PST > > > > > > FreeBSD src repository > > > > > > Modified files: (Branch: RELENG_5_2) > > > sys/i386/conf GENERIC > > > sys/alpha/conf GENERIC > > > sys/sparc64/conf GENERIC > > > sys/amd64/conf GENERIC > > > sys/pc98/conf GENERIC > > > Log: > > > Don't build a kernel.debug for the release. > > > > Out of interest, why not? The first request for additional > > information after a panic report is virtually always to perform a > > backtrace against a debug kernel to get line numbers. IMHO, having > > a debug kernel supplied with -RELEASE would seem very useful for > > people who don't rebuild their kernel. Note that, last time I > > checked, it is not at all clear that '-g' does not change the > > generated code so you can't guarantee to be able to do a '-g' build > > after the fact and generate a traceback. > > > > I'm not suggesting that kernel.debug has to be part of CD 1, but I > > believe it would make a worthwhile addition to (eg) the live > > filesystem CD. > > Not that I'm particularly involved with this aspect of things, but I > just burnt myself a CD image for the data center and found that I > didn't have room for the 50+MB debug kernel and debug modules, but I > was stunned at how well it did compress (~69%). > > % bzip2 -9c kernel.debug > kernel.debug.bz2 > % compress -c kernel.debug > kernel.debug.Z > % gzip -9c kernel.debug > kernel.debug.gz > % du -h kernel.debug* > 27M kernel.debug > 15M kernel.debug.Z > 8.3M kernel.debug.bz2 > 10M kernel.debug.gz > > Given the time difference between unzipping between bzip2/gzip (pretty > small, esp compared to the time required to bzip2/gzip something), I'm > surprised we don't make more liberal use of bzip2 on our releases. I I've been under impression that bzip2 has a lot more memory footprint compared to gzip; can this cause us any problems when deploying bzip2ed-FreeBSD on some pretty low-end/resource tight hardware? Otherwise, one probable should be more happy with 2.2.8 on it.. ./danfe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031210102535.GA3135>