After 3 months, Linus has released Linux 2.6.23. This version includes the new and shiny CFS process scheduler, a simpler read-ahead mechanism, the lguest 'Linux-on-Linux' paravirtualization hypervisor, XEN guest support, KVM smp guest support, variable process argument length, SLUB is now the default slab allocator, SELinux protection for exploiting null dereferences using mmap, XFS and ext4 improvements, PPP over L2TP support, the 'lumpy' reclaim algorithm, a userspace driver framework, the O_CLOEXEC file descriptor flag, splice improvements, a new fallocate() syscall, lock statistics, support for multiqueue network devices, various new drivers and many other minor features and fixes.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2006-06-21
And who's going to load just the modules that are actually needed by the machine? Modules get loaded automatically when a program attempts to access the relevant /dev devices. Some of them need configuration (module parameters and device-module aliasing) to work. Who's going to do that? Teoretically you could design software that can probe all the /dev entries known to mankind and still not obtain 100% accurate results.
And in order to do that you'd need to do what distro's already do (put together a full kernel), except instead of leaving it there and using what you need, you attempt to conduct a complicated hardware investigation, error prone, with the end result of deleting the full kernel you went to the trouble of producing and using a smaller subset of it.
And for what? You're losing perspective. Just to obtain a more lightweight kernel? Why? What distro's do today makes much more sense. Provide the full kernel and make software that looks at the hardware and uses the appropriate drivers.
I honestly don't see what a lightweight kernel would accomplish. The only time when kernel size matters is on small boot devices that simply don't have the space, but there are techniques to go around that.
Member since:2005-11-15
This is not how things work on linux, at least, not since udev started to be used, it was partially true on devfs era. Today almost all computers and devices come in one or another PnP flavor and they generate the appropriate event about their existence (and luckily, the kernel will recognize it). Your assertion about checking each /dev/* is flawed on these days. See the udev faq (small fraction follow):
"Q: Oh come on, pretty please. It can't be that hard to do.
A: Such a functionality isn't needed on a properly configured system. All devices present on the system should generate hotplug events, loading the appropriate driver, and udev will notice and create the appropriate device node. If you don't want to keep all drivers for your hardware in memory, then use something else to manage your modules (scripts, modules.conf, etc.) This is not a task for udev.
Q: But I love that feature of devfs, please?
A: The devfs approach caused a lot of spurious modprobe attempts as programs probed to see if devices were present or not. Every probe attempt created a process to run modprobe, almost all of which were spurious."
In other words, YES, it would be possible to streamline your kernel in a bit more sane way today (think about all the options you must turn off and also, what you should not touch, because, as you know, there are some interdependencies between some modules), without have to fight against kernel building failures.
Is the effort worth on face of all hassling? For some of us YES.
Member since:
2005-07-06
I agree there has to be a full blown kernel the first time the system is runnning. Thereafter a simple parse from lsmod
lsmod:
-------
Module Size Used by
vmnet 38416 13
vmblock 15520 3
vmmon 929636 0
nvidia 6211568 24
i2c_core 21632 1 nvidia
snd_intel8x0 29852 1
snd_bt87x 14792 0
snd_ac97_codec 89632 1 snd_intel8x0
snd_pcm 63620 3 snd_intel8x0,snd_bt87x,snd_ac97_codec
snd_timer 20100 1 snd_pcm
snd 37060 7 snd_intel8x0,snd_bt87x,snd_ac97_codec,snd_pcm,snd_timer
snd_page_alloc 11272 3 snd_intel8x0,snd_bt87x,snd_pcm
ac97_bus 6016 1 snd_ac97_codec
----------
should be enough to build a kernel with a leaner config.
So I'm afraid that in the end the human is needed to project everything that would be needed in a kernel.
Yeah a human to code.