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: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.
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:
2006-06-21
I'm not sure if I understand. You want a tool that would examine a system and produce the minimal kernel config that would cover all the system needs?
First of all, it's a chicken and egg problem. I'm not sure if you can discover certain system capabilities if the kernel doesn't already offer support for that capability. So you'd need a "full" featured kernel to produce the leaner one.
Second, some hardware is pluggable. USB printers, for instance. There's no way for a diagnostics tool to realise you need USB printer support unless you have one plugged in and turned on at examination time and if, again, you don't already have support for that.
So I'm afraid that in the end the human is needed to project everything that would be needed in a kernel.