Re: [Fwd: What do people think about not installing a stripped /kernel ?]

From: Brooks Davis <brooks_at_one-eyed-alien.net>
Date: Wed, 20 Oct 2004 14:37:20 -0700
On Wed, Oct 20, 2004 at 11:39:53AM -0600, Scott Long wrote:
> Brooks Davis wrote:
> >On Wed, Oct 20, 2004 at 08:20:48PM +0300, Maxim Sobolev wrote:
> >
> >>Let me clarify it down: it is only applies to HEAD, that is, unstable 
> >>branch, which can be inheretedly buggy. STABLE/RELEASE doesn't really 
> >>need this feature. This dismisses the following objections:
> >
> >
> >I think it's more important in HEAD, but personally I would like to ship
> >this way.  It has the potential to vastly improve the quality of bug
> >reports.  That's not my call though.
> >
> >
> >>1. HDD size constrains: nobody really want to run unpatched HEAD on CF 
> >>or the like, since with HEAD you are expected to re-compile more than 
> >>often.
> >>
> >>2. / partition size: anybody running HEAD is expected to allow this 
> >>accomodate debugging kernel.
> >>
> >>3. Additional slowdown: since it is adds up to 10 seconds (I bet that 
> >>even less on a modern system) who cares? This is HEAD, so that it is 
> >>expected to be sub-optimal performance-wise.
> >
> >
> >I seriously doubt it's measurable.  If it is, the loader is broken. :-)
> >We're talking about reading a section header and doing a seek for each
> >ELF section we don't care about (all the ones that bloat the file
> >relative to the stripped version.)
> 
> Actually, another possbility would be to have the kernel install target
> install the stripped kernel into /boot/kernel/kernel and the debug
> kernel into /var/kernel/kernel.debug or some similar location.

Some place in var seems like a good place to me.  We may want to bump
our default /var size a bit based on this but that's a minor detail.
The nice thing about /var/crash would be that everything you need to
debug a crash dump would be under a single hierarchy.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4

Received on Wed Oct 20 2004 - 19:37:21 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:18 UTC