Have something to say?

Ready to be published? LXer is read by around 350,000 individuals each month, and is an excellent place for you to publish your ideas, thoughts, reviews, complaints, etc. Do you have something to say to the Linux community?

I wonder what this means exactly

Bottomley refers to an internal Intel benchmark which I assume amounts to a test of each kernel with all the default kernel switches set. From my experience of compiling the kernel there is an awful lot of choice there (intimidatingly in fact).

So I am wondering if you were so inclined and technically competent enough, could you run through this compilation process and turn off most of the bloat? Or is Linus actually saying that the basic bare bones part of the kernel is becoming bloated because of the free for all nature of how contributions are assembled?

Would be interesting to know where the biggest problem was. I suspect with no evidence that it is all the options being turned on to handle the ever increasing diversity of modern hardware but that is a guess on my part.

What I think would be cool is an easier way to manage modules, and not by default end up with every video and networking interface driver in the world. I seem to recall the PCLinuxOS has an installation option to strip all the video drivers you don't need.

Yes that would be great. The qt interface at present is just a prettyfication of the usual text or ncurses interfaces along with a whole bunch of way too technical comments about what each option means.

I guess the kernel developers leave this sort of thing to the distributors and distributors are just interested in assembling a blackbox kernel that meets most users demands for hardware and stability.

The problem is that Linux has too much hardware support. What we need is a "Windows mode", where Linux only supports hardware that is supported by Windows. That would probably solve most of the problems with bloat.

I tink Mandriva also has a post-install option that removes all the unneeded drivers. I left them in though because I was a little uncertain what it would do when I plonk a USB device in there that was not detected at the time of install.

> I seem to recall the PCLinuxOS has an installation option to strip all the video drivers you don't need.

Debian has meta-packages for "xorg-input-all" and "xorg-video-all", and then Xorg autodetects (or finds in the xorg.conf) which specific one to use.

All it takes is disk space, and a considerate user can go back in and remove the unused drivers once he knows which one is in use. If PCLinuxOS's install checks first and then only installs the working driver, that would cut down on work. That's one good side-effect of installing from a LiveCD rather than a generic install disk.

For optimization of a working system, this is what I would like:

0) A tool that parses the loaded kernel modules and unloads what is not in use. While it would do little or nothing other than free up memory, I think it would be a public relations coup.

1) Automagic configuration of the configuration file for building a kernel, selecting only what is presently in use to be compiled in, everything else as loadable modules (just in case, a minimal waste of disk space and compile time, and the whole reason for loadable modules in the first place). Then building and installing of the custom kernel.

2) Optimization of the initrd.img for said custom kernel, making the assumption that catastrophic hardware changes have not been made since last time. Or would the optimized build above make the use of an initrd.img unnecessary?

3) Versioning of the above custom build so that if hardware changes have been made (or the magical build doesn't work), the "generic" kernel build remains available to start the process again.

Bigg, that would do pretty much what you're saying, cut the "supported hardware" to a minimum in the running kernel, while keeping module auto-loading "just in case". Like when plugging in a USB thumbdrive and needing FAT16 for the first time in years.

The last time I compiled a kernel was 2003, v2.4.xx, and even then the number of hardware modules to go through was awful. I can only imagine what it would be like now, so I'm right there with Monti in being intimidated. What that must be like for someone who has never compiled a kernel before....ugh! Serious intimidation.

It would be a nice project to do what you suggest and then use the Intel benchmark to verify speedups. If you then did it
for two quite different versions of the kernel (2.6.28 versus 2.6.14 say) you could check whether the bloat was coming
from the additional unneeded drivers or from Linus and team being less than optimal with the "base" kernel.....

> Bigg, that would do pretty much what you're saying, cut the "supported hardware" to a minimum in the running kernel, while keeping module auto-loading "just in case". Like when plugging in a USB thumbdrive and needing FAT16 for the first time in years.

What I have in mind is either (a) allowing the user to keep the installation CD around in case you install new hardware, or (b) automatically downloading available drivers, assuming you have a working internet connection.

I do not recall that I've ever compiled a kernel. It sounds scary. I'd much rather install a smaller kernel and add to it on an old machine.

> My understanding was that a kernel module was only loaded if you had hardware which needed it. Of course, that ignores things like the alsa-oss compatibility module and such, which alsa also loads.

From my experience, it is also possible to load a dynamic module that is not actually being used, if you deliberately do it "modprobe modulename" and its been included in the compile as a loadable module.

The alsa-oss and a LOT of other sound modules get loaded, true, just by turning sound on. I've enabled enough sound cards in the past by hand. More than enough.

So maybe my list of optimizations is redundant. Good! More demonstration that the Linux kernel environment is doing better than the sheer size of the source code might suggest.

It would be safer to say that the 'kitchen sink' kernels are indeed in need of a diet plan, then you have to add in the initrd,initramfs, or what have you on top of it. You plug it in and it works has a cost, and size/performance is that cost. What we really need is something that says, you only have this hardware and only need these controllers for your system, would you like to build an optimized kernel.

I do it by hand, and with one exception without an initrd or variant. Nice, small, and fast.

That would help (a lot) with speeding up module compilation but I'm not sure it would make a lot of difference with the slowdown noted by the intel benchmarks. After all when all is complete you will still be loading the same set of modules it's just that the rest won't be around.... I guess you could unload all the "useless" ones using rmmod before execution but my suspicion is that the biggest problem is with the builtin (non-modules) part of the kernel.

Edit: I notice Alan Cox links to Lxer. Maybe he (or someone like him) could comment instead of klutzes like myself who are speculating. ;-)

> ...it is also possible to load a dynamic module that is not actually being used, if you deliberately do it "modprobe modulename" and its been included in the compile as a loadable module.

Probably, but unless you expect the hardware to be present at least part of the time, why would you want to do that? On the other hand, a number of modules I've used in the past have checked for applicable hardware and wouldn't load unless they found it (mostly ethernet cards, from memory).

Ah, you see, I _don't_ want to do that. But I can, and have, because of hunting for the right driver for something before the days of semi-reliable auto-detection.

As Monte points out it's not just a problem of modules, but of which modules.

So something that merely reads what modules are presently loaded can make the error of over-provisioning. I really did mean "presently in use" in wish-list item 1, and that would also include un-selecting those modules which are compiled in the pre-mixed kernel but are unused.

I guess that's why it's called a "wish" list, it doesn't mean it's practical or workable.