All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Jaegermann <michal@harddata.com>
To: linux-kernel@vger.kernel.org
Subject: Re: /proc/config idea
Date: Mon, 2 Apr 2001 23:56:41 -0600	[thread overview]
Message-ID: <20010402235641.A813@mail.harddata.com> (raw)
In-Reply-To: <3AC91800.22D66B24@mandrakesoft.com> <Pine.LNX.4.33.0104021734400.30128-100000@dlang.diginsite.com>
In-Reply-To: <Pine.LNX.4.33.0104021734400.30128-100000@dlang.diginsite.com>; from dlang@diginsite.com on Mon, Apr 02, 2001 at 05:39:19PM -0700

On Mon, Apr 02, 2001 at 05:39:19PM -0700, David Lang wrote:
> 
> 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?)

After throwing away in a Makefile rule all "is not set" lines, as they
are trivially recoverable with 'make oldconfig', what is left for an
avarege kernel compresses to something like 500 bytes.  Quite a bit
of space left on this one page if you need more extensive .config.
'zcat /proc/config.gz' works just fine.

As most kernels around are NOT installed "the right way" I found that in
practice separating configuration information from a kernel image is not
even close to be semi-reliable on a longer run.  Those who say
"installation script", and similar things, assume that people compile
kernels for themselves.  This is undoubtely true for folks on this list;
this does not start to approximate the situation in general and, it
seems, that we really want it that way. :-)

BTW - /sbin/installkernel, as seen in practice, is not even correct for
a general case with x86; not to mention other architectures.  Writing
something like /var/log/config from "init data" during a bootup could be
another solution which does not take any kernel memory and still keeps
all this information attached to a kernel image itself.  OTOH we have
all these tons of strings which show in /proc/pci output and somehow
these do not cause such huge opposition.  Yes, I know that 'lspci' was
supposed to replace that; but it did not.

  Michal

  reply	other threads:[~2001-04-03  5:57 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
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 [this message]
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=20010402235641.A813@mail.harddata.com \
    --to=michal@harddata.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.