Kernel development

Kernel release status

The current development kernel is 2.5.70; Linus has not made a kernel release since May 26.

Linus's BitKeeper tree includes some device model work, a long-sought fix for hanging TCP sessions, an improved slab allocator which performs better in busy, multi-processor situations, some kbuild tweaks, an ALSA update, a set of hash function changes to deal with algorithmic complexity attacks, a FAT filesystem rework (if you have been waiting to be able to create FAT partitions greater than 128GB, this patch is for you), a v850 subarchitecture merge, a RAID update, the removal of the long-deprecated callout TTY device (/dev/cua) support, and several other fixes and updates.

The sixth version of the 2.6 kernel must-fix list is now available; it has been split into two separate lists: must-fix bugs and not-ready features and speedups. The list (pre-split) is also available in diff form.

The current stable kernel is 2.4.20. The current 2.4.21 prepatch is 2.4.21-rc7, released by Marcelo on June 3. "Now I really hope its the last one, all this rc's are making me mad."

Comments (none posted)

Safely suspending an IDE system

The 2.6 kernel will feature much improved power management, thanks to the device model, improved ACPI support, and a fair amount of effort in general to get power management right. One nagging problem remains, however, in the IDE subsystem. An IDE suspend or resume operation must be carefully serialized with any other operations happening within the same "hwgroup," where a hwgroup is a set of IDE devices that can only be accessed one at a time. Simply shutting down a drive when the kernel asks runs the risk of corrupting in-progress operations and generally making a mess of things.

Benjamin Herrenschmidt has now worked up a patch which deals with this problem, and, incidentally, shows off one of the design features of the 2.5 block I/O subsystem. The key to the solution is to realize that the IDE subsystem already has a mechanism which carefully serializes accesses to hwgroups: the block I/O request queue. If suspend and resume requests are put onto the request queue, the IDE subsystem will find (and act on) them at just the right time.

When one thinks of the I/O request queue, what usually comes to mind is commands to move data blocks to and from a drive. But, as covered in the LWN Driver Porting series, the newly redesigned block subsystem includes the ability to put other kinds of commands into request queues. This mechanism is used, for example, to queue packet-mode commands or explicit taskfile operations. But it can also be exploited to serialize power management commands.

So, all that was required is a new REQ_POWER_MANAGEMENT request type. The desired power management state is stored in the special field of the request structure, which is added to the target drive's request queue. When the hwgroup has finished up any other outstanding operations it may have going, it will see the power management request and deal with it at the right time. Problem solved.

Comments (none posted)

Where did that code come from?

SCO's lawsuit claims that code has been copied from its (or somebody's) proprietary code base into the Linux kernel. Beyond that, SCO claims that IBM, in particular, is responsible for that copying. These claims remain hypothetical as long as SCO refuses to provide any proof. As an intellectual exercise, let us imagine for a moment that SCO is actually able to produce examples of code that appear to have been copied from one system to the other. How then do they go about proving where it came from?

The kernel development process is nearly unique in a couple of ways. In one sense, it is one of the mostly tightly controlled projects out there; one - and exactly one - person can commit code to the mainline kernel tree. If Linus does not merge a patch, it simply does not go in. On the other hand, Linus did not use any sort of source code management system until early 2002. He also did not maintain any sort of records of what he merged, as far as anybody can tell; changelogs for kernel releases had to be created by digging through the large release-to-release patches and seeing what changed. So, while Linus is the "choke point" through which all patches pass, the record of what happened at that point is limited to his official kernel releases. One can look at Linus's output to determine, with great precision, when a particular patch went in, and, importantly, the evolutionary steps it took to get to its present state. Figuring out where it came from will be another story.

Since there is little information to be had from Linus on the provenance of patches before the BitKeeper era (which is the time period SCO is interested in), it will be necessary to try to trace any offending patches backward. And that means looking at how code reaches Linus. The basic nature of the submission process has not changed in a long time.

Some code is written by Linus himself. Linus's contributions have become a very small part of the whole, but he does still have something to add at times. It is probably safe to assume that Linus is not copying his work from proprietary Unix.

Some patches get to him by way of the linux-kernel mailing list. It is rare for Linus to pick up patches directly from linux-kernel, but it does happen. If a particular piece of allegedly infringing code was posted publicly, it should be possible to determine who sent it out. Chances are that the SCO investigators, if they really have infringing code to show, have been digging through the linux-kernel archives in the hopes of finding this sort of "smoking gun." The thought of SCO lawyers wading through old devfs flamewars is good for a smile or two.

Many patches go directly to Linus, often with no public posting at all. For example, much of Alexander Viro's work - big changes to core parts of the kernel - are first seen when they show up in a kernel release. There will be no record of these contributions other than Linus's memory and, perhaps, any existing backups of his mail spool. Unless this code comes with a comment like:

    /*
     * Copyright © Caldera International
     * 
     * Ripped off in 2000 by plagiarist@ibm.com; I'm too lazy to 
     * do this myself and they'll never notice.
     */

it will be very hard for SCO (or anybody else) to prove where the code came from.

The rest of the patches arrive by way of one of the "lieutenants" - developers like Alan Cox, David Miller, Greg Kroah-Hartman, Andrew Morton, and others. Some of these developers have used source management systems at times, others have not. Again, much of this code goes into the kernel without ever being posted on a public list. It can have two layers of private communication obscuring its true origin.

The end result of all the above is that the kernel development process is not quite as open as many people believe. A lot of code is posted publicly and its authors duly flamed for anything that does not look quite right. But a lot of code takes a quieter path and only sees the light of day when it shows up mixed into a development kernel. Much of the code that went into the 2.3 development series could be nearly impossible to trace back to its contributor.

It is also worth bearing in mind that no sort of paperwork is required to contribute code to the kernel. No copyright assignments, no warranties of originality, no indemnification. So there is no paper trail behind contributions to the Linux kernel - at least, not on the Linus side of things. One can only assume that companies like IBM have rather more rigorous procedures internally. But before that matters, a particular chunk of code will have to be traced back to IBM, and that could prove difficult.

The "low-ceremony" nature of kernel development is one of its attractions; the only thing you need in order to to play the game is some worthwhile code. It would be a shame if legal pressures eventually forced Linus to erect a wall of paperwork between himself and aspiring contributors.

For SCO's purposes, however, it is too late. Unless an IBM employee went out of his or her way to attach their name to a code contribution via a public posting or internal comments, it may never be possible to prove the origin of that contribution. And that could be bad news for SCO, which has gone out of its way to state that IBM, in particular, is responsible for the copying that SCO claims has occurred.

Comments (12 posted)