Linked by Thom Holwerda on Tue 9th Oct 2007 22:07 UTC, submitted by diegocg
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.
Permalink for comment 277574
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Recent Original Stories
Recent Comments
Headlines
Random Comments
Random Stories
Random OS Link
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.