|
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. |
Adrian Bunk has proposed a simple adjustment to the current kernel development method. Currently, the official kernel tree does a few weeks of new code acceptance, followed by a few weeks of modification and stabilizing efforts. Further stabilization occurs in the w.x.y.z tree after the official release, which places tight restrictions on the type of patches that may be accepted.
In Adrian's proposal, this would remain the same, except that, after each official release, the previous w.x.y.z tree would relax its patch restrictions to resemble what we had in the days when even releases pursued stability and odd releases pursued development.
Once 2.6.17 came out, for example, Adrian would have the 2.6.16.z tree continue its development along the same lines as the 2.4 and 2.2 trees, pursuing overall stability while cautiously accepting back-ports and additional updates.
The current thinking of Linus Torvalds, Andrew Morton, and other primary maintainers is that Linux distributions now have the responsibility of stabilizing the kernel for their own releases. Officially, distributions are recognized as an integral part of the development process that takes care of stability. This decision wasn't done by consulting with distribution makers. It just recognizes that distributions release their own heavily patched kernels; that most people use distribution kernels; and that stability testing was included in each distribution's modifications.
The official w.x.y.z tree was created to handle the most egregious stability issues in the main tree. Tight limitations were put on this tree, precisely because Linus didn't want it to become another development branch. In light of this, Adrian's proposal amounts to a suggestion that the current indifference of the development model to stability has not worked, and that we need to go back to something more along the lines of what we had before. Not surprisingly, it turns out this is a controversial issue. But it is one that will come up again.
One of the biggest objections to Adrian's idea is that it would just take more work and be more boring than anyone could stand. Linus has said this of the initial proposals for the w.x.y.z tree, and people are saying it now to Adrian. The problem with that argument is that we had many stable series that worked. And Linus's objection that stabilization is "boring" is more a reflection of his personal taste. But there have been numerous attempts to create a stable tree in the old style.
However, even the maintainers of the w.x.y.z tree, a much more restricted and constrained project, affirm that the problems with a more active stabilization effort are virtually insurmountable. But if nothing else, Adrian's suggestion does show that at least some kernel developers find the w.x.y.z tree, and the reliance on distributions to stabilize their own trees, insufficient.
Silicon Graphics code was inadvertently accepted into the kernel with a big restrictive copyright notice, effectively putting the Linux Kernel into copyright violation for a period of several months. As it turned out, the SGI engineer who submitted the code just forgot to change the licensing terms to the GPL in the header file. This oversight was an honest mistake that was easily corrected, but the fact is that this kind of mistake happens maybe a couple of times per year.
Linus Torvalds has implemented a kind of tracking system, where each patch reviewer "signs off" on a patch's quality and legality. This new tracking system was specifically created to prevent future inconveniences from SCO-like attacks, so that Linus could quickly and easily track down the true origins of any piece of code in the kernel and avoid any legal violation.
Although the tracking system is not perfect, perhaps it doesn't really need to be. The SCO attack was intended to damage Linux, and it succeeded to the extent that kernel developers had to adopt a little bit of bureaucracy to protect themselves.
A perfect system would involve even more bureaucracy, but this would make it even more difficult for developers (especially newcomers) to contribute to kernel development.
The new miniconfig feature initiated with kernel 2.6.15 is getting a lot of attention from developers. Miniconfig allows users to specify only the kernel features they want; the build process takes care of enabling all additional dependencies.
Because miniconfigs are so much simpler than full config files, they tend to be portable between kernel versions; they can be edited by hand without breaking anything; and when you read them you see all the main features the kernel will support.
Rob Landley is involved in much of the work to extend miniconfig. He's implemented a new make miniconfig build target. With this, instead of using a miniconfig file to generate a full config file prior to compilation, make miniconfig will generate a new kernel directly from the miniconfig itself. It's a much more convenient mechanism than what 2.6.15 has by default.
Rob has also written a script to generate a miniconfig file from a full config file, essentially whittling all dependencies out of a given config file until only the primary features remain. Currently, this script is extremely slow. The script takes the iterative approach of rebuilding a full config file after each feature removal and seeing how this affects the result. While slow, it does work, and the possibility exists to find faster methods of miniconfig construction.
Pavel Machek recently implemented a prototype version of software suspend with much of its functionality outside the kernel and just a minimal kernel interface. The interface part is actually still being discussed, as it's hard to choose from the numerous imperfect options available.
Dave Jones has said that if Pavel's plan goes through, Red Hat will probably fork off its own version of software suspend, because their kernel has rootkit prevention patches that would interfere with writing to arbitrary memory regions. Also, Dave considers userspace software suspend misconceived from the start.
But the folks at Red Hat can relax, as acceptance of Pavel's patches will not necessitate removing any existing features. Both methods of software suspend could co-exist peacefully for a good while, before any decision is made.
Nigel Cunningham is also working on a version of software suspend that has its own issues. For one thing, it's a lot of code to put into the kernel. For another, if Pavel is right, a lot of what Nigel's code does could also be done just as well in user space.
None of the folks involved in software suspend seem to get along very well, and discussions tend to devolve into flames.