Re: Improved INCLUDE_CONFIG_FILE

From: Gavin Atkinson <gavin.atkinson_at_ury.york.ac.uk>
Date: Mon, 26 Mar 2007 10:44:16 +0100
On Sun, 2007-03-25 at 23:55 -0500, Eric Anderson wrote:
> On 03/25/07 09:34, Gavin Atkinson wrote:
> > On Sat, 24 Mar 2007, Wojciech A. Koszek wrote:
> >> On Sun, Mar 25, 2007 at 08:00:41AM +1000, Peter Jeremy wrote:
> >>> On 2007-Mar-24 15:32:00 +0100, Robert Watson <rwatson_at_freebsd.org> wrote:
> >>>> On Sat, 24 Mar 2007, Wojciech A. Koszek wrote:
> >>>>> I'd like to have this enabled by default, and I know there should be no
> >>>>> strong objections.
> >>>> I agree -- the memory used by it is very small compared to the amount of
> >>>> memory in modern systems, and the potential administrative benefit is very
> >>>> large.  As long as it remains an option, the embedded folk can turn it off
> >>>> easily.
> >>> Ideally, we would include it in a .comment section that wasn't loaded.
> >>> Unfortunately my ELF-foo isn't up to this (I've tried something similar
> >>> many years ago and couldn't get the linker to DWIW).
> >> In my current implementation, kernel configuration content is converted
> >> to the string and is actually put into separate ELF section. However,
> >> it's not .comment but a loadable section, since otherwise you wouldn't
> >> be able to obtain the configuration of a running system.
> > 
> > strings `sysctl -n kern.bootfile` | grep ^___ | sed -e 's/^___//'
> > 
> > should still work if it was in a .comment section
> 
> Unless you no longer have the running kernel, or it has changed since 
> the boot up of the system.  A sysctl knob to dump it is *very* useful.

Would it?  The main benefit that I see is to be able to say "That kernel
config doesn't boot, what did I have in my last kernel?".  I can't think
of a single situation where you would be likely to have a kernel still
running, but no longer have a copy of it in /boot/kernel
or /boot/kernel.old.

Note that I'm not against the suggestion, I just don't think I see the
point.

Gavin
Received on Mon Mar 26 2007 - 07:44:26 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:07 UTC