Zack’s Kernel News

Kernel Documentation

At least two significant documents have come to light recently. The first, from Josh Aas, documents the CPU scheduler for the 2.6.8.1 kernel – apparently still a very popular kernel in production systems. Josh’s employer, SGI, owns the document, and has released it under the GNU Free Document License. Stelian Pop recently released a HOWTO document describing how to properly track Linux kernel developments with the Subversion revision control system. This document has been somewhat controversial, representing, as it does, a challenge to BitKeeper. Developers circumventing BitKeeper by using Subversion, arch, or any other tool, tend to want better support from BitMover for their alternative; and while Larry McVoy is willing to go very far to help BitKeeper users, he has been very reluctant to help BitKeeper’s competitors. And it seems he is not without justification. He has made a successful business out of BitKeeper, and the free software world has apparently been unable to create anything to displace it. A new favorite topic among kernel developers is how development should proceed now that the even/odd stable/development ideas have been abandoned. Many developers are unhappy with the current situation, saying it is impossible to trust recent kernels. Others say it’s great to be able to continue contributing new ideas and not wait for a development series. Andrew Morton has acknowledged the difficulties of the current system. Few people, it seems, are testing the 2.6-rc releases, while point releases are tested heavily. Point releases are therefore less stable than release candidates, because bugs discovered in each point release are fixed during the candidate cycle, even as new features are added or enhanced. One possibility that seems to be bubbling closer to the surface is that the 2.6.x.y numbering scheme could be used to stabilize point releases.

New “Hot Fix” Branch of The 2.4 Tree

In consultation with Marcelo Tosatti, Willy Tarreau has created a so-called “Hot Fix” kernel tree to contain fixes slated for the next official 2.4 release. The reason for this is that two months or more can elapse between official releases, and the -hf tree will fill this gap, making up-to-date stable kernels available earlier. Fixes will include security updates, critical fixes for panics and data corruption, major fixes for oopses and memory leaks, minor fixes, and problems with the build system. This is one of those developments that addresses the specific needs of a small minority of users, while compromising the traditional goal of keeping the 2.4 tree a ‘stable’ branch. All the excitement in the 2.6 tree has not affected Marcelo’s commitment to stability in the 2.4 tree; although he may have been talked into accepting more backports than he would have if 2.6 had followed a more conventional approach.

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.

Twilight Zonefiles

The kernel is a strange thing. When it works, it is beautiful. When it breaks, there is often nothing pretty about it. But sometimes an apparently harmless malfunction just looks so strange that you have to laugh. Wichert Akkerman experienced one of these recently. With an ext3 filesystem under a 2.6.10-ac10 kernel, he noticed the df command reported his disk usage at 101%, and the number of available blocks was reported as -73786976294838127736. There seemed to be no data loss or corruption, just this weird report that went away after an fsck. A less mysterious but no less startling problem was discovered by Mitch Williams. He found that seeking into a file in SysFS, and then writing to that spot, would not write at the desired location but would instead overwrite the entire file with the new data. Trying to append to a file in SysFS would do the same. This came as a shock to folks like Greg Kroah-Hartman, who has put a lot of work into SysFS; but apparently, the way SysFS is used does not tend to trigger this sort of bug very often. People typically don’t modify SysFS files. They usually want to replace the values contained within the file completely. Still, this is clearly the wrong behavior, and SysFS should behave like a regular filesystem for file operations. Mitch has submitted a patch to fix the behavior.

New Plans For Version Numbering

The kernel development process seems to be sloughing off another dry skin, revealing a new incarnation related to version numbering. There are two main aspects, neither of which are etched in stone (or even soft). The first is that Linus Torvalds and Andrew Morton are considering a return to the even/odd version numbering scheme to differentiate stable and development releases, but with a twist. Instead of only the minor version number having significance with regard to even/odd parity, they plan to extend this division to all three numbers – major number, minor number, and patch number. As Linus has proposed, the significance of an odd-numbered digit increases the farther left it is found. So, if all three numbers are even (2.6.14 for example), then this will represent a week or so of stablization effort. If the patch number is odd (2.6.13), then the goal is still primarily stability, but that kernel will be the result of somewhat larger changes, over the course of a month or two. If the minor number is odd (2.7.10), this kernel has been aiming for large changes that may de-stablize the kernel for several releases over the course of a year or two. And if the major number is odd (3.0.0), it indicates there have been huge breakages and massive code rewrites, and that Linus is recovering in the hospital. It does not appear that the final “yes this will happen” has been given, but it is rare that any kernel process change is given a clear starting point, let alone a clear definition. Linus prefers an extremely iterative approach, which is difficult for journalists to pin down, but this approach often results in new and unsuspected improvements in basic kernel development. The second new aspect of kernel development is something that has been brewing for some time. The creation of the X.Y.Z.A numbering scheme, dubbed by Linus, “the sucker tree,” because anyone who would agree to maintain such a tree would have to be a “sucker.” The reason for this is that under the constraints discussed on the kernel mailing list, this tree will be difficult to maintain, with few rewards, fewer accolades, and plenty of abuse from irate users. Linus wants very tight controls on the X.Y.Z.A tree to ensure that only fixes that are absolutely loved by all developers go in. Patches must be clear bug-fixes only. They will have a two-day waiting period to allow developers to object to their inclusion. Only if they survive that waiting period may they be accepted. Linus will pull all patches from that tree into his own for whatever stage of development or instability his is in. Users desiring stability in their kernel will be able to use the “sucker tree” with much more confidence than the main kernel. Greg Kroah-Hartman has become one of the primary maintainers of the “sucker tree” and has released 2.6.11.1 with three small bug-fixes against 2.6.11.