Stephen R Laniel wrote:
On Wed, Apr 20, 2005 at 11:25:58AM +0200, Matthias Kaeppler wrote:So only 2 and 3 are sane options for you I guess, but whether you're running an Intel or AMD CPU is something you should know yourself :pThis relates to a question I often have. Let's say that I want to compile a customized kernel for my machine that only compiles modules for hardware that I have, is tailored specifically to my processor (right now a Pentium M 1.5GHz), compiles into the kernel only those modules corresponding to hardware that is always attached to my computer (hence wasting no memory), etc. As of right now, the easiest way to do this isn't easy at all: I have to go through a long list of kernel options and pick the ones that apply to me. This often involves knowing extreme arcana about my machine. Quite often this arcana can be deduced from a combination of a) lspci, /proc, etc., b) general knowledge of my system (I have no gaming hardware), and c) inferences from other hardware selections I've made (the Hopkins Frommit 831G contains a Kerwin Dingle 918X Fromulator, so if I select the former I should also select the latter). But I'd really like a computer to take care of this for me. So are there any packages that will {semi-,}automate the kernel-install process for me?
Hm yes, I also thought of this recently. I just rolled a 2.6.11 kernel for my new notebook a couple of weeks ago, and I noticed that since 2.6.7 a lot of new options were available, making the kernel config even more tedious and time consuming than it already had been.
This made me thinking about where this will end in the future. For sure, new kernel releases will add new features and complexity for still quite some time and might become unmanagable by a normal user. So it may be about time to create a utility which does the low level config and only asks the user for e.g. driver options which couldn't be automatically determined.
Unfortunately, I'm not aware of any such tool as of now. Your best bet is probably to:
a) Use a stock initrd kernel, which will only load the modules for the detected hardware (e.g. as found by the 'discover' tool). The current stock kernel for Debian Sarge is 2.6.8, but IIRC it's modified by the Debian devs/packagers and should run with less flaws than a 2.6.8 from kernel.org. Of course you will have loads of stuff in /lib/modules/<kernel> which will never be used, but I guess some wasted space is worth the avoided trouble. For most hardware, those stock kernels do a pretty good job.
b) Take a heart and go through the config /once/, flag as much as you can to be compiled as a module, and backup your config. If you at some time want to change e.g. a driver setting, you don't need to rebuild the whole kernel, but can select the new module (or deselect old ones), and just run `make modules && make modules_install`, which is sufficient to incorporate the changes. Also no reload of the LILO boost loader is needed (in case you use it, GRUB never needs this). If you ever happen to upgrade your kernel, copy the backed up .config to /usr/src/<new-kernel-version> and run `make oldconfig`. This will build the new kernel based on your old config, and only ask for those options which are new.
I know all this stuff isn't too satisfying. I wish there was a better option.
-- Matthias Kaeppler