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-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:2006-03-23
in essence, just build the kernel with everything non essential to boot as modules, and your kernel will be as small as required, since only stuff you use will be loaded...
and with this in mind, there are 2 choices:
1(for the person not caring about disk space): build ALL shit as modules, since we know only required stuff will be loaded
2(for people caring about disk space): build only modules you actually want
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.