Kernel development

Kernel release status

The current development kernel is 2.6.0 (we're not quite ready to call it a fully stable kernel yet). This kernel was released by Linus on December 17, right after last week's LWN Weekly Edition went out saying it hadn't been released. Linus, we think, does this on purpose. Anyway, this kernel contains a small number of very small patches; see the long-format changelog for the details.

As of this writing, there are no patches in Linus's BitKeeper repository.

The current stable kernel is 2.4.23; Marcelo released the second 2.4.24 prepatch on December 22. This prepatch adds some ACPI fixes, various driver updates, an XFS update, and various other fixes.

Comments (4 posted)

2.6.0 is out - now what?

Linus and Andrew have, at long last, released the 2.6.0 kernel. What happens now?

If you are a potential user of the new kernel, and you have not worked with 2.5-series development kernels thus far, there are some resources to check out:

• Dave Jones's Post-Halloween document, which has been updated to 2.6.0. Here you'll find an extensive description of what has changed, what issues remain, and what tools you may have to update to run this kernel.

• Joe Pranevich's Wonderful World of Linux 2.6 continues his tradition of documenting the features available in the new stable kernel.

• Andrew Morton's notes on what to expect from 2.6.0 are also worth a read.

If you are a developer looking to update out-of-tree code to the new kernel (and there seem to be quite a few people answering to that description out there), we humbly recommend the LWN.net Driver Porting Series. It answers a number of questions which have been posted to linux-kernel recently.

Where do things go from here? As Linus pointed out in the 2.6.0 announcement, Andrew Morton is now the maintainer for 2.6. This is the first time that Linus has passed off responsibility for the stable series before moving on to the new development tree. So the most likely place to look for patches likely to go into 2.6.1 (and subsequent kernels) is Andrew's -mm tree, currently at 2.6.0-mm1. That tree contains an impressive 384 patches, some of which are significant. There are also quite a few patches in the hands of their respective developers which will surface as soon as it appears they might go in.

Looking at all of these patches can be a little discouraging; it is easy to envision a 2.6.x kernel which, after a big patching frenzy, is rather less stable than 2.6.0. Certainly things have worked that way with some previous stable kernel releases. There is cause for optimism, however. Andrew has a strong interest in keeping the stable kernel truly stable, and many of the patches in -mm have been there for quite some time. Not all of the -mm patches will go into 2.6, but those which do will have already been put through their paces by users of the -mm tree.

The question of more interest to many developers is: when will the 2.7 tree open up? The stabilization period between 1.0 and 1.1 was all of 34 days. With 1.2, however, things began to stretch out; it took 97 days before 1.3 started. Developers waited 113 days for 2.1 and 105 days for 2.3. The delay between 2.4.0 and 2.5.0 was the most stressful of all for kernel hackers; it took a full 323 days. There is reason to hope that the wait for 2.7 will not be anywhere near as long; 2.6.0 is in better shape than 2.4.0 was. But it would be surprising if the stabilization period were shorter than it has been for other 2.x releases. So we can expect to wait at least three months, putting the beginning of 2.7 sometime in March, 2004 or thereafter. But that, of course, is just a guess.

Comments (1 posted)

Improving kill_fasync()

Unix systems, and their variants, provide a number of ways for processes to manage multiple I/O streams simultaneously. One of those is through the use of I/O signals; a process can request to receive a SIGIO whenever a given file descriptor becomes available for reading or writing. Inside the kernel, this signalling is handled via a file-specific fasync_struct structure and a couple of helper functions. One of them, called fasync_helper(), simply helps the kernel (filesystem or driver) code track which processes have requested notification for a given file. The other, kill_fasync(), is invoked to actually deliver a signal to interested processes when the time comes.

The kernel uses a single reader/writer spinlock (fasync_lock) to serialize all calls to either helper function. In some situations, it would seem that this lock is starting to hurt performance. It seems that more types of devices support I/O signalling than was once the case, and the increasing number of calls to kill_fasync() is creating lock contention. So Manfred Spraul did something about it, in the form of a patch which switches the I/O signalling code over to the read-copy-update mechanism for mutual exclusion. The result for his particular test load was an 80% reduction in the time required to send out I/O signals.

Linus, having issues with how some of the locking was done, didn't much like the patch, But he also had some ideas for reworking the whole I/O signal mechanism to get rid of a lot of unneeded code. The key is in the understanding that the list of processes wanting I/O signals is very similar to the list of processes simply waiting for the I/O itself. Either way, it is a list of processes that needs to be notified when data becomes available or the file descriptor becomes writable. There is not a whole lot of difference between sending a SIGIO to the process and simply waking it up.

During the 2.5 development process, the wait queue mechanism was generalized somewhat; this Driver Porting Series article describes some of the changes which were made. The kernel function wake_up() (with several variants) is called to wake processes which are waiting on a wait queue; in 2.4 and prior kernels, it performed that wakeup directly. In 2.5, however, all wake_up() really does is call a special wakeup function, a pointer to which is stored in the wait queue entry. This indirection allows different processes to be awakened in different ways.

So far, there are few cases where a non-default wakeup function is used. But there is no real reason why, with a suitable wakeup function, wait queues could not be used for any of a number of different process signalling tasks. The whole I/O signalling mechanism and its fasync_struct structure could really be replaced by a wait queue with a special wakeup function.

The only problem with this nice, elegant idea is that it won't work. kill_fasync() takes a "band" argument which eventually gets passed though to the target process as signal data. There is currently no way to pass that information to a wakeup function via wake_up(). Adding a data parameter to wake_up() would fix that problem and, perhaps, enable a number of other potential uses for wait queues. Such a change appears likely to happen - but not until 2.7. Such changes really shouldn't be made in 2.6, now that the 2.6.0 kernel has come out.

Comments (1 posted)

Use of patented code in the kernel

A kernel developer recently asked: should code implementing an algorithm known to be patented be submitted for incorporation into the Linux kernel? Given that Linus has promoted an approach to software patents in the past that some see as being a bit cavalier, one might be forgiven for not knowing the answer in advance. But Linus's answer was clear: "Don't submit, and find an unencumbered algorithm."

The two points of view expressed by Linus are entirely compatible. Code which is known to have patent encumbrances cannot go into the kernel, because such inclusion is (or could lead to) a knowing act of infringement. On the other hand, kernel developers should not go out of their way looking for potential patent problems with their code. That way lies madness -- there's no end of bogus software patents out there. Known problems should be kept out of the kernel; the rest should not be worried about until something comes up.

That said, a couple of interesting points were raised in the discussion. One is that the exclusion of patented code hurts all users of the kernel, even though many of them (a majority, even) are, for now at least, in jurisdictions which do not recognize the patents in question. Rather than exclude code with patent encumbrances, why not create a configuration option making the code available to those who can legally use it? The burden would then be on the end users to think about what they can do before explicitly turning on an option which would enable patented code.

Various objections can be raised to this scheme, of course. It would turn our free kernel into a partially proprietary system, at least in some countries. Patents are public knowledge, so publishing an implementation should not be a problem as long as the patented code is not used in places where the patent is recognized. But somebody might still try to file a suit complaining that the kernel (and its developers) are contributing to an infringement. The community also does not need another reason for certain critics to proclaim that Linux is putting its end users into legal danger. For all these reasons, the inclusion of patented code with a configuration option seems unlikely.

There is one other potential issue, however; as Jamie Lokier pointed out, there is already some code in the kernel with patent issues. There is a documentation file in the kernel source which discusses the SB-Live mixer code - and patents which may cover it. If there is a license which allows those patents to be used in the kernel, the file fails to mention it. The kernel also contains a "flash translation layer" memory card driver; the FTL format it implements is subject to a patent owned by M-Systems. The license that goes with that code allows the use of the patented technology - but only with PCMCIA cards. The covered code is, thus, not entirely free.

Given the nature of the software patent regime (especially in the U.S.), it seems certain that more patent-encumbered code will be found in the future. It would not be surprising if, one day, we were faced with a patent covering an important piece of code in a heavily-used kernel subsystem. At that point, some difficult choices will need to be made. Until then, however, there is little to be done.

Comments (11 posted)