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

[Alexey Dokuchaev]

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