Easier kernel configuration with 2.6.32

Didier Spaier · 12-07-2009, 05:34 PM

According to release notes for Linux-2.6.32 @ kernelnewbies.org:

Quote:

1.8. Easy local kernel configuration

Most people uses the kernel shipped by distros - and that's good. But some people like to compile their own kernels from kernel.org, or maybe they like following the Linux development and want to try it. Configuring your own kernel, however, has become a very difficult and tedious task - there're too many options, and some times userspace software will stop working if you don't enable some key option. You can use a standard distro .config file, but it takes too many time to compile all the options it enables.

To make easier the process of configuration, a new build target has been added: make localmodconfig. It runs "lsmod" to find all the modules loaded on the current running system. It will read all the Makefiles to map which CONFIG enables a module. It will read the Kconfig files to find the dependencies and selects that may be needed to support a CONFIG. Finally, it reads the .config file and removes any module "=m" that is not needed to enable the currently loaded modules. With this tool, you can strip a distro .config of all the unuseful drivers that are not needed in our machine, and it will take much less time to build the kernel. There's an additional "make localyesconfig" target, in case you don't want to use modules and/or initrds.

That's good news for those of us needing or wanting to build a new kernel and using a Slackware config file as a starting point

swampdog2002 · 12-07-2009, 06:22 PM

That is interesting news, and which will be very useful. On this note, I have always wondered if it was problematic with using a .config file from an earlier kernel release to use to build a new kernel from source. For example, if going from 2.6.29.6 to 2.6.32, if you load the .config from 2.6.29.6 into 2.6.32 when compiling, would problems result from this? The reason I ask is that I have done this before, and noticed when I loaded an older .config from an older kernel branch that there a few text exceptions thrown in the background, but couldn't quite make them out due to the kernel configuration menu being in the foreground. All seemed to build well with no errors in the process, so I don't know. Anyway, I'll be trying this new method in the future to see what results. Thanks for sharing this.

Daedra · 12-07-2009, 06:35 PM

This is very interesting. I'll have to give this a try when I get off work tonight. Thanks for the heads up. I always have my custom configs saved but maybe this can help me thin out a few unneeded modues.

Chuck56 · 12-07-2009, 06:46 PM

Nice find. Thanks!

drumz · 12-07-2009, 08:14 PM

As to using an old config file, yes it's what I always do. Copy the old .config file to your new build directory and then run

Code:

make O=/your/build/directory oldconfig

And it will only ask you questions for new or changed features. After that you can double check with menuconfig/xconfig to make sure it's how you want it.

localmodconfig does look interesting but I haven't used it yet. I feel like I already have my configuration the way I want it. Of course there's always room for improvement.

Daedra · 12-08-2009, 04:22 AM

So I just tried it out using 2.6.32 with a custom .config from 2.6.30.10. I managed to shave off 45kb from the finished kernel. I'm impressed.

BrZ · 12-08-2009, 05:31 AM

And:

Quote:

It's worth mentioning that the 'low_latency' setting defaults to on.

Sounded very cool =]

samac · 12-08-2009, 06:43 AM

Very useful for people who do not "chop & change" their hardware. If this works well it should be possible to take a newly installed system with a huge.s kernel, run a script and have a kernel (optimised for your system) created and automatically added to your boot loader.

samac

~sHyLoCk~ · 12-08-2009, 06:51 AM

Has anyone tested this yet? I will be trying it out this weekend, too much work now. Let us know your experience if you have done it.

Didier Spaier · 12-08-2009, 06:56 AM

... But I would start with a generic kernel as if I understand well the only removed drivers with "make localmodconfig" are among those previously configured as modules.

sahko · 12-08-2009, 09:30 AM

Thanks for the news. Very interesting and very needed.

wadsworth · 12-08-2009, 12:33 PM

A couple of gotchas.

Modules that aren't already loaded won't be available with your new kernel,
plug in a USB stick before running "make localmodconfig". Or else no USB support.

Support for filesystems not currently in use will also be removed.
Check the config for excluded filesystems you may need (XFS, JFS and the like).

H_TeXMeX_H · 12-08-2009, 12:56 PM

Thanks, this is useful info and will probably save plenty of time when building a kernel. Thanks also goes out to all the Linux kernel devs that made this possible.

Personally, I would start with perhaps a generic kernel, then run the 'make localmodconfig', then 'make menuconfig' and make sure things look good. You may want to enable some things that were not detected, but I'm sure it will help in keeping the kernel small, and possibly fast.

~sHyLoCk~ · 12-08-2009, 10:32 PM

Ok I finally did it. Now with a customized 2.6.32 kernel. localmodconfig is quite useful but not that well implemented yet. I had inserted my USB drive before running localmodconfig, but at the end of the compilation process I was left without any USB support. I did a make clean and make menuconfig again to check out what happened and saw that "USB Mass storage support" was off and many USB options weren't auto-detected. My soundcard module wasnt picked up either. It's a generic Intel sound card. So I had to enable those modules and recompile kernel. Now everything works great. However this option did help me getting rid of a lot of unnecessary stuffs quite easily.

Didier Spaier · 12-10-2009, 07:52 AM

I just tried "make localmodconfig" and it worked well.

My starting point was a 2.6.32 kernel already slightly customized and stripped down from a Slackware generic 2.6.29.6 kernel.

As space on disk is not really an issue here, major visible benefit is (a lot) less time to run "make modules". FYI anyway:

Code:

bash-3.1$ du --max-depth=1 -h /lib/modules/
75M     /lib/modules/2.6.29.6
40M     /lib/modules/2.6.32
14M     /lib/modules/2.6.32strip
65M     /lib/modules/2.6.29.6-didier
193M    /lib/modules/
bash-3.1$

As seen through "make help", "make localyesconfig" could be handy too for people preferring having everything built-in.

Caveat: as already said, plug in your USB devices (or, more generally, removable devices) needing a specific driver first, or at least take a note of the modules they use so you can add it afterwards. For instance issue "make localmodconfig" then "make menuconfig" to add what would have been be missing.