public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Jackson <jerj@coplanar.net>
To: Jeff Garzik <jgarzik@mandrakesoft.com>
Cc: Ian Soboroff <ian@cs.umbc.edu>, linux-kernel@vger.kernel.org
Subject: Re: /proc/config idea
Date: Mon, 02 Apr 2001 20:37:47 -0400	[thread overview]
Message-ID: <3AC91B5B.1612945D@coplanar.net> (raw)
In-Reply-To: <877l13whzw.fsf@danube.cs.umbc.edu> <3AC89389.46317572@coplanar.net> <3AC91800.22D66B24@mandrakesoft.com>

Jeff Garzik wrote:

> 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

not in the kernel in an ELF section, marked not loadable.  it never leaves the
disk.
as someone else posted, it's ~900 bytes gzipped (if you want to have it in core)

unfortunately (in the LILO case) x86 doesn't boot an ELF image... (oops)

>
> memory, folks.  There is no need to special case an operation as simple

If you have a lot of kernels around, which Config-2.4.3 applies to kernel 2.4.3
given 5 to choose from...the idea (same for System.map) is that it being in the
same
file they can't be confused.  Kinda like forks under Mac (but let's not go there
now)

>
> as reading a file.  [I think this about firmware images too, but that's
> another thread]


  reply	other threads:[~2001-04-03  0:45 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-02 13:25 /proc/config idea Ian Soboroff
2001-04-02 14:58 ` Jeremy Jackson
2001-04-02 15:19   ` Brian Gerst
2001-04-02 15:28   ` Bart Trojanowski
2001-04-03  0:23   ` Jeff Garzik
2001-04-03  0:37     ` Jeremy Jackson [this message]
2001-04-03  0:49       ` Jeff Garzik
2001-04-03  2:52         ` David Lang
2001-04-03 11:18           ` Olaf Titz
2001-04-03 12:27           ` Alan Cox
2001-04-03 12:43             ` Jeremy Jackson
2001-04-03 14:32               ` Alan Cox
2001-04-03  0:39     ` David Lang
2001-04-03  5:56       ` Michal Jaegermann
2001-04-03 14:13       ` J . A . Magallon
2001-04-03 18:46         ` Ben Ford
2001-04-03 19:11           ` Alan Cox
2001-04-03 19:12           ` J . A . Magallon
2001-04-03 19:30             ` Mike Castle
2001-04-04 11:56               ` GOMBAS Gabor
2001-04-03 20:57             ` Ben Ford

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3AC91B5B.1612945D@coplanar.net \
    --to=jerj@coplanar.net \
    --cc=ian@cs.umbc.edu \
    --cc=jgarzik@mandrakesoft.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox