|
The Linux kernel mailing list comprises the core of Linux development activities. Traffic volumes are immense, often reaching 10,000 messages in a 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. |
Jose Luis Perez Diez pointed out that Perl 5 was actually required by the kernel build system to create documentation, graphs, and even headers and firmware; however, this fact was not documented anywhere. He posted a patch to the CHANGES file, listing the Perl dependency along with all required Perl modules. My guess is that many kernel hackers will be stewing at their consoles over this patch, having argued for many years against introducing a Perl dependency, then - lo and behold - finding it right there in the kernel. Their displeasure will not likely be mollified by the inevitable suggestion that the Perl engine be embedded in the kernel and the implementation be forked to provide kernel-specific enhancements.
Denis Karpov has added a Sysfs interface to alert the user when the kernel becomes aware of possible filesystem corruption. When this happens, the /sys/block/<bdev>/<part>/fs_unclean file will contain a value of 1. The user has to either fix the problem or confirm that it was a bogus alert. After that, the user must manually reset the value contained in that file to 0, typically with an echo command. In addition, Denis has created a uevent that will occur under the same condition.
Luis R. Rodriguez asked how he could volunteer to review patches for the stable kernel releases (2.6.x.y). Chris Wright replied that Luis's email was sufficient and added him to the review list. When Stefan Bader saw how easy it was, he asked to be added, too, and Greg Kroah-Hartman added him. This brought the total number of volunteers to 17, and Greg thought that the CC list might be getting a little too long for some email clients. He suggested starting a new mailing list, or else using the existing stable-commits list. Chris liked the stable-commits idea, but he said it was really just read-only. Greg suggested creating a stable-review list, and Chris said he'd take care of setting it up.
David S. Miller has taken over as IDE maintainer from Bartlomiej Zolnierkiewicz. David says he's going to treat IDE as legacy code that will have to be supported, but without attempting to remain cutting edge. The PATA drivers, he says, are where users should be going, and IDE will not be competing with those.
Bartlomiej gave David his full support and offered to help out if necessary. Meanwhile, Steven Rothwell asked whether the linux-next tree should switch to using David's new Git repository at master.kernel.org:/pub/scm/linux/kernel/git/davem/ide-2.6.git, and David agreed that this was the way to go.
Gabriele Turchi wrote and posted a little driver to support the Asus Eee PC touch screen. Without the patch, the touch screen itself would be detected, and it could be used to generate mouse button events, but mouse movement was not supported. Andrey Panin forwarded the patch along to the linux-input mailing list; however, there was no discussion about this contribution.
Eric Paris announced that he and Dan Walsh had created a security sandbox using SELinux, the idea being that users would be able to isolate untrusted executables and run them in a secure environment. Among other things, this would allow large groups of arbitrary users to participate in clustering without having to trust the upstream source of the clustered software fully. Read Dan's original blog post on the subject at: http://danwalsh.livejournal.com/28545.html.
Jon Masters has set up kernelpodcast.org with a semi-daily summary of events in the kernel development world in the form of podcasts and audio transcripts. We wish him the best of luck with it - it sounds like a great project!
Incorporating the Xen virtualization patches into the official kernel tree has garnered a lot of interest. Xen lets users create multiple virtual computers on a single piece of hardware, which is useful for getting close to 100 percent utilization out of a given system (e.g., in a server farm). The prospect of one day getting Xen into the official sources is enough to set the toes of Xen developers everywhere a-dancing in their socks.
Recently Ingo Molnar suggested that this step might be a good idea, and, not surprisingly, a number of folks voiced support and began discussing which of Xen's sprawling elements to include or exclude in an initial patch set. Theodore Ts'o also approved of the idea, and Steven Rostedt compared the whole situation to Xen folks asking for an apple and getting apple pie instead.
Some people also voice their opposition. Alan Cox said, "Start by changing the mentality. Right now much of the patched code looks like `We made a decision years ago when creating Xen. Now we need to force that code we wrote into Linux somehow'." He suggested that merging Xen was less important than creating the appropriate framework in Linux to support Xen. He also restated this, saying he felt Xen's implementation might just be wrong. He suggested "turning off" Xen features to get a minimal implementation that could be architected properly and merged into the kernel with minimal problems, then more stuff could be added over time.
Part of the problem, as Theodore pointed out, is that accepting a poor design into the kernel would make it very difficult to fix later because users must continue to be supported in future kernels. A bad decision in the early days of a Xen merge could make various regions of the kernel harder to maintain or debug for a long time into the future.
Various Xen advocates argued against some of these suggestions. George Dunlap pointed out that such a fundamental reimplementation, along with dropping so many of Xen's existing, working features, would essentially mean starting an entirely new project - which would be quite different from Xen - from scratch.
Theodore and others started offering suggestions of how the project might work and how merging Xen as-is might ultimately end up being much more costly. But the Xen folks seemed to be getting more and more frustrated with that line of thinking. Ultimately, Linus Torvalds joined the discussion, saying, "You're totally missing the problem. If Xen was a single driver thing, we wouldn't have this discussion. But as is, Xen craps all over OTHER PEOPLE'S CODE. When those people then aren't interested in Xen, why is anybody surprised that people aren't excited?" And elsewhere (in a different thread) he added, "Xen pollutes the architecture code in ways that NO OTHER subsystem does. And I have never EVER seen the Xen developers really acknowledge that and try to fix it."
So on the one hand, there are plenty of developers, users, and businesses who'd love to see Xen in the kernel, not just eventually, but right now. And on the other hand, the Xen codebase apparently makes very invasive, unwelcome changes all over the kernel, in addition to implementing interfaces that might cause long-term maintenance and support issues in future versions of Linux. Given all that, my guess is that the kernel folks will continue to refuse to accept Xen in its current form and that the Xen folks will have to figure out - probably with some pain - exactly where the compromise point will be. Probably discarding all of their hard-earned features would not be necessary, but certainly some parts of Xen would have to be reconceived.
At the same time, it also seems clear that a number of top kernel developers, including Alan Cox, are friendly to Xen and would be eager to help clarify what exactly would be acceptable for the Xen folks to submit into the kernel. It could be some time, perhaps months or years, before the controversy and bitterness resolves itself into a true cooperative effort. The recent discussion, for example, was more of a flame war (with the kernel folks on the more peaceful side) than a technical consideration of what to do.