lkml.org 
[lkml]   [1998]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [IDEA] Developers: your opinion badly needed ! (Was: [PATCH] /proc/config.gz)
From
Date
Michael Meissner <meissner@cygnus.com> 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
> | idea...no 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 System.map, 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
name

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
strings]

- 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?

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.033 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site