Re: [IDEA] Developers: your opinion badly needed ! (Was: [PATCH] /proc/config.gz)

Andi Kleen (
02 Jun 1998 20:47:04 +0200

Michael Meissner <> writes:

> | I want to voice my 2 cents...
> |
> | Having a /proc/config is a good idea.
> |
> | Having to match static files with a running kernel is a bad
> | matter how careful you are, you may make mistakes (assuming
> | you can find the file).
> |
> | The solution for /boot/*-${VERSION} is not sufficient when
> | multiple kernels exists for the same version...
> |
> | When you need this information, you want ACCURATE infomation, not a guess
> | (multiple files are a guess).
> The same goes for /lib/modules/<version>. I wish there was a subversion #, so
> that when I'm playing with a particular release, I don't wipe out the modules
> compiled earlier. For example, I have a SMP machine, but I sometimes want to
> build a non-SMP version of the kernel as a backup (for examples, some revisions
> of the kernel, the Adaptec SCSI controller didn't work too well in SMP mode).
> Since the version # is the same, it means interoperability problems if I use
> the wrong kernel with the /lib/modules. For example, where extra files are
> appended to vmluniz, but not brought in, could be extended to all of the
> modules, in addition to, and .config. That way, you only have one
> file to save/move around, etc.
> A lot of these posts going on about kernel bloat, seem to be from people who
> manage ONE linux machine where it is easy to keep track of the details. I
> suspect people who need to manage multiple machines (particularly multiple
> machines of different configurations) have real problems that aren't being
> addressed. For example, I found it harder than it should be to build a kernel
> + modules on my Pentium Pro machine to be installed on my laptop (not having a
> global prefix for both kernel + modules install, meant I had to either install
> it on my workstation, wiping out the current config, or installing it later on
> the laptop, which didn't work because the pathnames created weren't the same).
> While I'm at it, it would be nice if each linux release came in a separate
> directory with a revision #, instead of just 'linux'.

There is actually one nice thing from the BSD way of doing kernel compiles:
they use a configuration file and with that the kernel configuration has a

I propose the following for linux to support 'configuration names' too:

- Add a way in config/menuconfig/xconfig to enter a 'Configuration name'

- Use this name as postfix for .config, e.g. instead of
/usr/src/linux/.config the configuration file shall be named
/usr/src/linux/.config.NAME. The default configuration could be saved
in /usr/src/linux/.defaultname

- Add a elegant way using the existing "oldconfig" mechanism to configure
the kernel tree for different named configurations, e.g.
make CONFNAME=myothermachine oldconfig
Or even better:
make CONFFILE=/some/where/else/config-file oldconfig
The same variables could be used for config/menuconfig/xconfig to allow
editing non-default configurations.

- Save the configuration name of the kernel in the kernel and output it
with uname [it would be good if this name could be saved somewhere in the
uncompressed header of zImages too, so that it would be possible to identify
the kernel name of a zImage without needing to unpack the kernel, e.g. with

- Change modules_install to install in /lib/modules/X.Y.Z-confname

- Save the configuration name in modules too. This could be done using a
static declaration in include/linux/modules.h [this would mean some
duplication for multifile modules, is it possible to declare initialised
data as 'common' too?]

- insmod/modprobe could be fixed to first search in /lib/modules/X.Y.Z-confname
before looking into /lib/modules/X.Y.Z

What does the list think?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to