|
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. |
Although we've had a "stable" w.x.y.z kernel series for quite awhile, the primary maintainers, Greg Kroah-Hartman and Chris Wright, have so far not been listed in the MAINTAINERS file in the main kernel. This came up as a problem recently, when Steven Rostedt tried to find the email address to send bugfixes to the folks maintaining the stable tree. He found it, but the incident raised the issue of where this information should be stored; and the MAINTAINERS file seems to be the most natural place. Steven submitted a patch listing Greg and Chris as co-maintainers; and Greg accepted the patch into his own kernel tree, to feed up to Linus Torvalds and Andrew Morton.
Meanwhile some controversy has broken out among some of the top developers over a closely related issue. Greg has given maintainership of just the 2.6.16.z tree to Adrian Bunk. The plan is for Adrian to continue to release 2.6.16 stable patches for a much longer time than the stable tree maintainers would do. So while Greg and Chris move on to support 2.6.17, 2.6.18 and beyond, Adrian will stick with 2.6.16, refining it to a high degree. The git repository for this is git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git
The reasoning behind this goes back to the whole question of how to provide a good, stable kernel. The w.x.y.z tree does a good job of addressing some of the issues involved, but it does nothing to support stable interfaces across versions. If some developer interface changes between 2.6.x and 2.6.y, that interface will also change in the stable series for each of those kernels. So the interface itself would not be stable, though both versions might work perfectly in their respective kernels. By continuing to accept stability patches against 2.6.16, Adrian hopes to avoid this problem. Users who need the features of the 2.6 tree, but who also need a high degree of interface and run-time stability, will be able to rely on Adrian's tree for both of those things. In a way, Adrian's tree can be seen as a `feature freeze' for the 2.6 tree.
There are various difficulties Adrian will face. One of these, as Willy Tarreau has pointed out, is that the official 2.6 tree will continue to diverge from Adrian's 2.6.16 fork (which is really what it will be), but Adrian will still need to back-port fixes from the main tree to his own; and distributions and other users relying on Adrian's tree will expect and perhaps need him to get all those fixes. So the work involved in the project will be non-trivial.
The controversy sparked by this whole issue is unfortunately somewhat acrimonious. Andrea Arcangeli seems to have personal objections to the selection of Adrian as 2.6.16.z maintainer, and to Greg as one of the overall stable tree maintainers. This appears in part to stem from a disagreement over how the GNU General Public License actually covers the kernel, and whether binary modules are or are not legally allowed. This is an ugly, ugly issue, involving historical statements by Linus Torvalds as to what was allowed; as well as the fact that Linux itself consists of a patchwork of code all owned by their original contributors and released under the GPL, making it virtually impossible to adjust the kernel license in any way at all. Whatever the lawyers ultimately decide about the kernel, that will be what we are stuck with. There will in all probability be no option for someone like Linus to clarify or relicense the code in response to those legal judgements. So disagreements on these issues among kernel developers tend to cut deep.
I don't know the full nature of Andrea's and Greg's beef with each other over this or other issues. But apparently because of these things, Andrea objects to the whole idea of Greg appointing Adrian to maintain this new tree; or even of Greg initiating a new stable tree at all. But many of Andrea's objections are technical and not personal or political. For instance, from a practical standpoint, Andrea wants to see a stable kernel that people will actually use; with the new system, in addition to the official 2.6 stable tree maintained by Greg and Chris, users will also have the choice of Adrian's 2.6.16 stable series. To Andrea, this will only serve to confuse and fragment the user base.
Andrea also objects to the fact that Greg simply selected Adrian for this important task, without giving any sort of call for applicants. But this objection seems to hold a bit less water. As Alan Cox points out, "Linus has always taken the approach of picking who he trusts to hand stuff onto, as have others." According to Alan, "2.6.16-stable is in the hands of someone that Greg [...] thinks is a good person to do the job. That sounds to me quite sensible selection criteria, and Adrian is certainly up to the job."
Alan Cox has announced an overarching plan to merge libata PATA support from Andrew Morton's -mm tree into the main kernel tree in the near future. A longer-term goal is to eliminate the old IDE layer entirely. As Alan puts it, "Many of the new libata drivers are already more stable and functional than the drivers/ide ones." Mark Lord, the initial creator and earliest maintainer of the IDE subsystem, is strongly in favor of Alan's plan, and has said, "it is time to get the next generation code upstream."
There seems to be no serious dissent among kernel developers. The loudest debate seems to be about how to name disk devices in the future; but even this is somewhat muted by Alan and others who call this a udev issue, rather than something that need concern the kernel directly. Still, the issue of naming is significant, and udev can't simply pick any device names it wants - it must support existing usage, or risk breaking a lot of user-space software.
Mingming Cao forked an ext4 filesystem from ext3 on August 9th. Already there is a push to get these patches into Linus Torvalds' tree "as early as possible," as Andrew Morton put it. The floodgates are now open for all the old ext3 patches that Linus objected to, such as extents and greater-than-32-bit block sizes.
Andrew and others argue for a lot of ext3 cleanups before actually forking the code. This would theoretically make it easier for developers to port fixes between the two trees; but this is not as straightforward as it might sound. By moving perhaps too quickly, the kernel developers risk inadvertently destabilizing the ext3 code. Jeff Garzik sugests the the best approach is to fork the tree first, do the cleanups in ext4, see if they do no harm, and then migrate them to ext3 after testing.
It is clear that ext4 will very quickly be available to users. Some users may ask why ext4 should get into the official tree so easily, while filesystems like Reiser4 do not. The simple answer is that the ext4 developers are able to work within the kernel development process, while the Reiser developers - particularly Hans Reiser himself - resent the process and consistently try to subvert it. Whether or not you agree with this preferential treatment, it is the way kernel development and maintainership is currently handled.
Kaz Kojima has stepped down as co-maintainer of the SuperH architecture. SuperH is a RISC architecture used in embedded devices. Kaz has said that the major SuperH development issues had shifted to hardware he had no access to, and lately he has turned his attention to other projects. Paul Mundt, the other co-maintainer of SuperH, `acked' the patch, thanking Kaz for his years of support for that code, and also hinting that it might be possible to get Kaz any hardware he currently lacked. But Kaz did not immediately jump at that opportunity.