|
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. |
Work on the git and Cogito revision control tools continues at an amazing pace, with the project itself receiving over thirteen hundred patches since it became self-hosting barely two months ago.
Kernel projects are rapidly switching from BitKeeper to git. NTFS was one of the early adopters. Since then, libata, JFS, the net driver code, and ALSA have all switched. Marcelo Tosatti's 2.4 tree has switched, along with Greg Kroah-Hartman and Chris Wright's w.x.y.z stable tree. Andrew Morton has decided not to use any version control for his -mm tree, but Matthias Urlichs has written a script to gate -mm development into a git repository on a patch-by-patch basis, so a full history will be available for that tree as well.
BitKeeper has virtually vanished from Linux kernel development. It's remarkable how quickly kernel development has returned to normal - even better than normal. Some developers have said that in some ways, git and Cogito allow them to work even more efficiently than they ever worked under BitKeeper.
Nevertheless, the sudden loss of BitKeeper, and the need to create a replacement, has delayed the kernel development process, particularly the release of the 2.6.12 kernel. The delay has gone on long enough that kernel developers have begun to ask about it. A new release should come out within a week or so, possibly before this article sees print. The 2.6.12-rc3 release was the first to use git. Since then, there have been 3 additional -rc releases, all with git. At one point, Andrew Morton suggested that the 2.6.12-rc6 release (already out) would be the last one before 2.6.12; this remains to be seen.
A host of auxiliary tools and services appear to be cropping up all around git development. Martin J. Bligh and a lot of IBM folks have put together an automated testing system for Linux kernel releases - supporting official releases as well as the git nightly kernel snapshots. The kernel.org site, home to all Linux kernel releases, has put up a web page allowing folks to browse the several dozen git repositories currently hosted there. You may visit them at http://kernel.org/git/. A number of other web-based (and some standalone) git-browsing tools are also available. The mailing list formerly used for BitKeeper changeset announcements has been repurposed for git patch commit announcements.
And of course, git itself is under constant development by many strong developers. Linus continues to take an active role, but he is attempting to hand off pieces of the project to various others, notably Petr Baudis, who maintains Cogito. Junio C. Hamano is also extremely active, as are many others. It is likely that over the next few months, Linus's participation in git and Cogito development will continue to wane, and the project will take on a life of its own. Undoubtedly, it will continue to cater heavily to Linus's wishes.
When the new w.x.y.z stable series first emerged out of the mosaic of considerations for where to go with 2.6, Linus Torvalds did not think it had much chance of success. He felt the task of maintaining such a tree would be too onerous; no one would be willing to put up with its demands for long. And he did create a set of very strict requirements, regarding exactly which patches could be accepted into the w.x.y.z tree, and how long they had to be considered before acceptance. He even called it the "sucker tree."
Greg Kroah-Hartman and Chris Wright decided to take on the responsibility, and since then they have produced nearly a dozen releases. There were a few bumps at first - patches accepted that Linus felt should have had more consideration. But w.x.y.z development now seems to have settled into a fairly predictable routine. Greg or Chris announce a new set of patches; folks discuss them for several days, and then, based on that discussion, a new release comes out.
Developers such as Jeff Garzik and Alan Cox have praised Greg and Chris's work, confirming that the w.x.y.z tree is indeed more stable and a better tree for production work. The reliance of kernel development on Linux distributions for stability no longer seems to be as true - the kernel is beginning to stand on its own, even as 2.6 development makes deep changes to the code.
The IDE driver is once again inspiring developers to flame each other into fine powdery ash. Maintainers of this important and problematic driver seem destined for pain. This time Alan Cox and Bartlomiej Zolnierkiewicz were the combatants. Alan - who rescued IDE from itself during the early 2.6 period - feels the entire IDE layer is degenerating into broken code; while Bartlomiej - the current maintainer - responds to the criticism by saying nothing has been broken, no functionality has been removed, and Alan has had plenty of opportunity to argue about each patch as it was posted to the mailing list.
The IDE curse runs deep, not in the code so much as in the hardware itself. With all the IDE standards and their incompatible implementations, the IDE maintainer must somehow intuit all the special cases, refinements, conflicting versions, and difficult-to-identify hardware, and make it all work. It is no help that IDE is one of the most crucial pieces of the Linux kernel. If even a small fraction of IDE drives fail to work correctly under Linux, there would be a huge outcry. IDE simply must work.
Because of the importance of the IDE layer, some extremely powerful developers have attempted to maintain it. Mark Lord did the job for years, until he finally cracked after a relatively minor dispute with Linus. Andre Hedrick gave his all on the project, but he too was driven slowly insane by the project. Martin Dalecki, at Linus's request, took over IDE in 2.5; he attempted to fix it with a sledgehammer, but was ousted by developers frustrated by the fact that IDE was broken in every kernel release. Alan finally fixed the driver himself, transforming the impossible into the ordinary; but he was unwilling to remain IDE maintainer after that, and Bartlomiej ended up with the job.
Now it's unclear what will happen next, but if the past is any indicator, Bartlomiej has a tough row to hoe.
Markus Klotzbuecher has written a tool called mini_fo that can apparently do the impossible: allow users to write data to read-only files and filesystems. No, this tool does not create any security violations, and there is no risk to user files. Markus's new "virtual" filesystem works by misdirection. The tool creates a user-writable area elsewhere on an appropriate filesystem, and it then layers data from that area onto the read-only filesystem. Users appear to be editing files in the read-only area, but really they are simply creating a patch.
When a user tries to read the files, the user sees the original read-only files, with the new changes layered on top of the original. To the user, it is as if the read-only file has been altered. The uses for this sort of tool are manifold, starting with embedded systems programmers who want to maintain a read-only area, but still allow users to configure and alter that area.