|
The Linux kernel mailing list comprises the core of Linux development activities. Traffic volumes are immense, often reaching ten thousand messages in a given week, and keeping up to date with the entire scope of development is a virtually impossible task for one person. One of the few brave souls to take on this task is Zack Brown. Our regular monthly column keeps you abreast of the latest discussions and decisions, selected and summarized by Zack. Zack has been publishing a weekly online digest, the Kernel Traffic newsletter for over five years now. Even reading Kernel Traffic alone can be a time consuming task. Linux Magazine now provides you with the quintessence of Linux Kernel activities, straight from the horse's mouth. |
Marcelo Tosatti's 2.4 tree is in deep maintenance mode, with no more code or drivers being backported from the 2.6 kernel. With 2.4 virtually stationary, and 2.6 continuing its development cycle, the question of how to deal with kernel stability is likely to come up again and again. While Linux distributions are expected to handle much of the stabilizing process on their own, and the w.x.y.z tree attempts to draw each new kernel release closer toward stability, these efforts address primarily up-time, without concerning themselves with changes in kernel behavior itself.
As 2.6 continues to develop, its interfaces continue to change to some extent, making it more difficult for third party software developers to write software that will work reliably across 2.6 versions. This issue may grow more intense over time, until something as good as the old even/odd development cycle comes about.
Greg Kroah-Hartman continues his campaign to remove DevFS from the kernel. Since the 2.6.13 release, the option to enable DevFS has been unavailable to users, and it appears that no one has heard an outcry. Since that time, Greg has posted patches against every major kernel release to remove the DevFS code entirely; and now he's done the same against 2.6.16 - and Andrew Morton has accepted this change into his -mm series as well.
It's clear that DevFS is going away, if not from 2.6.16, then still soon enough. But apparently there may always be a remnant of it in the kernel, in the Documentation/ioctl-number.txt file. The existence of DevFS must be recorded there as having used its ioctl numbers, so they can't be reused by anything in the future.
As part of the transition away from DevFS, Greg continues to maintain his very small alternative, ndevfs.
Mariusz Mazur has had to abandon his linux-libc-headers project. One of the perennials of kernel complaints is that users want to include kernel headers in their user-space software. Kernel developers insist this should never be done, but it doesn't stop software writers from wanting it. Mariusz's project enabled it, but only at the expense of some very ugly code that (according to Linus Torvalds) would never make it into the kernel in that form.
So, Mariusz's patch kept getting larger, as new kernel releases deviated further and further from this hack. The time it took to port the feature to new kernels increased as well, until it became too much. However, the need for linux-libc-headers still exists, and several kernel folks have decided to take it under their wing and see if a way of maintaining it as a group can be found without overwhelming any single developer. While the details are being hashed out, a great pile of kernel developers have jumped on the various underlying design problems in an effort to come up with an approach that might one day be acceptable to Linus.
Whether Mariusz will leave the project entirely, or play a significant role in a larger effort, remains to be seen. Likewise, whether the project itself will find a single maintainer, or a group of maintainers, or whether it will have its problems solved immediately during this new fervor, also remains to be seen.
H. Peter Anvin has brought klibc to the point where he feels it's ready for inclusion in the main kernel tree. This project intends to create a very small libc, small enough to be included within the kernel binary itself and made accessible in situations where the big libc is unavailable.
Various folks are happy to see this work progressing, and are interested in helping to test and/or port the code. One interesting aspect of all this is, as Antonio Vargas pointed out, the Linux kernel seems to be moving gradually toward a more and more modular structure, pushing into user-space in an almost microkernel-esque way.
Linus Torvalds commented on this a few years ago, saying he would like to see more and more formal communication paths within the kernel to create a more modular and independent structure; he just wasn't willing to make the kind of efficiency sacrifices that microkernel advocates were willing to make.
Adrian Bunk has submitted a patch to remove RAW1394_REQ_ISO_SEND and RAW1394_REQ_ISO_LISTEN from the kernel, saying the new ioctl-based rawiso interface is more efficient. So in theory, the kernel should still provide the same level of support. However, Gene Heskett and others are unhappy, because ieee1394 has apparently been broken since Linux 2.6.13-rc1, while the 1394-devel mailing list appears very quiunresponsive to bug reports. Gene has a nifty new Sony DVR-TVR460 movie camera that has not worked for him under Linux since the 2.6.13-rc1 release.
Like Xen, VMWare is working on implementing paravirtualization to allow multiple instances of Linux to run natively (or near-natively) on their hardware. This is accomplished by having the Linux kernel itself inform the VMWare system of certain activities it performs. This provides a great speed improvement over VMWare's previous efforts at full virtualization.
Moreover, VMWare wants the interface between itself and Linux to be generalized into something any other virtual machine could use, so (it says) there is no intention to create a specialized proprietary interface within the kernel.
Ultimately, VMWare would like paravirtualized kernels to be the default kernel compiled on any system, thus allowing users to trivially launch multiple kernels at the same time.
Jörn Engel has posted a patch to remove blkmtd, as there has been a working alternative that has received no bug reports for over a year. Apparently, blkmtd interferes with H. Peter Anvin's efforts to merge klibc; and there seems to be no reason to keep it, anyway.
Jörn's patch elevates the block2mtd feature, making it the default method of viewing memory devices as block devices. Andrew Morton accepted the patch practically before it was submitted, saying, "Let's just zap it," and send it along to Linus directly, without fermentation time in the -mm tree.
git no longer requires forking off a diff invocation. Linus Torvalds has implemented diff support internally, cutting git diff generation time down to a sixth of what it was. It also makes git more portable in general, since there is no longer any need to worry about forking under Microsoft OSes.
Alex Riesen tested Linus's patch under Cygwin and reported execution time cut down to a fiftieth of what it was. Instead of his test taking a couple minutes, it took a couple seconds. As Linus said, "That's the difference between `unusable' and `pretty damn good'."