Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S131676AbRDCAqm>; Mon, 2 Apr 2001 20:46:42 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S131832AbRDCAqd>; Mon, 2 Apr 2001 20:46:33 -0400
Received: from warden.digitalinsight.com ([208.29.163.2]:20981 "HELO
	warden.diginsite.com") by vger.kernel.org with SMTP
	id <S131676AbRDCAqQ>; Mon, 2 Apr 2001 20:46:16 -0400
Date: Mon, 2 Apr 2001 17:39:19 -0700 (PDT)
From: David Lang <dlang@diginsite.com>
To: Jeff Garzik <jgarzik@mandrakesoft.com>
cc: Jeremy Jackson <jerj@coplanar.net>, Ian Soboroff <ian@cs.umbc.edu>,
   <linux-kernel@vger.kernel.org>
Subject: Re: /proc/config idea
In-Reply-To: <3AC91800.22D66B24@mandrakesoft.com>
Message-ID: <Pine.LNX.4.33.0104021734400.30128-100000@dlang.diginsite.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

yes it's unreclaimable memory and that's why we want to minimize how much
is used.

on the other hand there is a factor of reliability in the kernel knowing
what options were used to compile it that you just cannot match with a
seperate file, or even with it a part of the on-disk image that is thrown
out when it gets loaded into memory.

if the distro/sysadmin _always_ installs the kernel the 'right way' then
the difference isn't nessasarily that large, but if you want reliability
on any system it may be worth loosing a page or so of memory (hasn't
someone said that the data can be compressed to <1K?) make it so that you
need a common external tool to use the data and deliver it from the kernel
in compressed form and you don't even need to put the decompression
routine in the kernel (cat /proc/sys/kernel/config |gunzip >config)

David Lang

 On Mon, 2 Apr 2001, Jeff Garzik
wrote:

> Date: Mon, 02 Apr 2001 20:23:28 -0400
> From: Jeff Garzik <jgarzik@mandrakesoft.com>
> To: Jeremy Jackson <jerj@coplanar.net>
> Cc: Ian Soboroff <ian@cs.umbc.edu>, linux-kernel@vger.kernel.org
> Subject: Re: /proc/config idea
>
> Jeremy Jackson wrote:
> > Yes, I like this.  I do this manually, it allows reproducability, and
> > incremental
> > modifications, tracing how that kernel on that problem system was made...
> >
> > I think the ultimate would be to put all of .config (gzipped?) in a new ELF
> > section without the Loadable attribute...  I wish System.map was the same.
> > The you're guaranteed you know how a kernel on disk was configured.
> >
> > To correlate a running kernel to one on disk (vmlinuz) you have LILO...
> > it appends an environment variable to the kernel command line with
> > the name of the file it booted.  This is not infallable, since LILO maps
> > disk sectors, only using the filesystem at map install time.
> >
> > Permaps an md5sum of the .text ELF section would conclusively
> > link the in-core kernel with an on-disk vmlinuz?  Shouldn't be hard
> > to do with objcopy and /proc/kmem?
> [...]
> > Comments anyone?
>
> Instead of doing all this stuff in the kernel, you could simply update
> symlinks to properly installed files at boot time.
>
> Putting _files_ in the kernel is plain silly.  This is unreclaimable
> memory, folks.  There is no need to special case an operation as simple
> as reading a file.  [I think this about firmware images too, but that's
> another thread]
>
> --
> Jeff Garzik       | May you have warm words on a cold evening,
> Building 1024     | a full moon on a dark night,
> MandrakeSoft      | and a smooth road all the way to your door.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/