Messages in this thread | | | Subject | Re: [IDEA] Developers: your opinion badly needed ! (Was: [PATCH] /proc/config.gz) | From | Andi Kleen <> | Date | 02 Jun 1998 20:47:04 +0200 |
| |
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
| |