See also: last week's Kernel page.

Kernel development

Update: 2.5.5-pre1 was released just as this page was going to "press." It includes the ALSA sound system (see below), the new input driver scheme, the X86-64 merge, and a bunch of other stuff.

Dave Jones's latest prepatch is , which adds a number of fixes to the 2.5.4 release. This one should compile for most people.

Guillaume Boissiere's has been updated for 2.5.4.

The current stable kernel release is still 2.4.17. The first 2.4.18 release candidate was released on February 13; if all goes well it will become the next stable release.

Alan Cox's latest is 2.4.18-pre9-ac3; it adds the latest reverse mapping virtual memory patch, an updated DRM implementation, and a number of fixes.

Those who prefer a development-oriented 2.4 kernel can see 2.4.18-pre8-mjc from Michael Cohen. It adds the reverse mapping VM, the preemptible kernel patch, the new 2.5 scheduler, User-mode Linux, and many other things.

The preemptible kernel patch was merged into 2.5.4-pre6, thus ending, by fiat, a long debate on whether it was a good idea or not. This patch was discussed in detail almost a year ago on this page; it has evolved since then, but the basic idea remains the same.

There is still some nervousness about this patch. Anything that changes one of the basic assumptions of the kernel programming environment (that kernel code runs to completion unless it explicitly yields the processor) does need to be looked at carefully. The fact that kernel code will not be preempted when it holds a spinlock reduces the problem to something similar to the SMP situation - but not quite.

In particular, there is an increasing amount of processor-specific data used by the kernel. Limiting access to a specific data structure to a single processor brings some significant performance benefits - that data stays in a single processor's cache. It was also possible, until now, to work with single-processor data without locking; since no other processor will try to access that data, there is no need to lock the other processors out. If kernel code is preemptible, however, processor-specific data is no longer safe; other measures must be taken.

The preemptible kernel patch has been well tested over the better part of a year, and the obvious glitches have been worked out. Even so, chances are that a surprise or two remain - though there have been few complaints so far. Preemption makes the kernel more responsive, and is worth having. But it is a good patch to have integrated early in the 2.5 cycle.

Here comes ALSA. Jaroslav Kysela announced the availability of an Advanced Linux Sound Architecture patch for the 2.5.4 kernel. The announcement showed a certain degree of frustration - apparently Linus had not been answering mail from the ALSA maintainers, and they were not sure what the situation was.

Things have since settled out. Here's : My main reason for being silent on it has been that I've been doing other things. I'll be merging ALSA in the not too distant future, but it's not been a high priority for me like some of the other stuff I have spent my time on.. And that, of course, is what happened; ALSA is in the first 2.5.5 prepatch.

ALSA will not immediately amaze Linux users with lots of new capabilities. For the most part, the only thing people should notice in the short term is that sound on their systems works as always. What ALSA brings is a new and more coherent design, a nice kernel API (which is normally hidden behind the well-defined library API), support for professional hardware, and better MIDI sequencing and routing support. A thorough emulation layer ensures that old OSS sound applications will work as always, but quite a few applications also support the ALSA native API.

In the longer term, the combination of ALSA and the low-latency work should help ensure that Linux is capable of handling the most demanding audio tasks.

How synchronous should sync be? Andrew Morton has posted fixing a perceived problem with the sync() system call: as long as processes keep generating data, sync() will keep flushing it to disk. The result is that a sync command can take a long time to execute - as in several minutes. Andrew's patch changes sync() to just ensure that all data to be written when the call is made gets out - buffers generated thereafter may not be written immediately.

This patch, of course, changes a fundamental assumption made by many who use sync - that, upon completion, all data has been written to disk. In fact, according to the Single Unix Standard, this behavior is permissible: "The writing, although scheduled, is not necessarily complete upon return from sync()" It is, regardless, not the behavior that many expect.

There's no real consensus on what the proper behavior is. Unless Linus takes the patch, the current sync behavior will remain.

Other patches and updates released this week include:

Core kernel code:

• Christoph Hellwig has a new version of his kthread interface, which attempts to rationalize the creation and management of kernel threads.

• Here's the latest version of Rusty Russell's patch implementing easy per-CPU data areas.

• Rik van Riel has released version 12e of his reverse-mapping virtual memory patch.

• The 2.5.4 Linux security module patch is available.

Development tools:

• of the Linux Test Project test suite has been released.

• of the patch enabling the gcov test coverage tool to be used with the kernel has been posted by Hubertus Franke.

Device drivers

• A new has been posted by Greg Kroah-Hartman. "It differs from my previous patches, in that this one works well."

• Jens Axboe has posted a patch implementing queue barriers in the block I/O layer. Barriers allow higher level code (such as a journaling filesystem) to require that all data queued before the barrier is written to disk before any data after the barrier. A 2.4 version of this patch was posted by Chris Mason.

Filesystems:

• The University of Michigan has announced the first release of its NFSv4 implementation. This patch still has some rough edges, and only works with the 2.4.4 kernel (yes, 2.4.4 - a 2.5 port is in the works).

• Andrew Morton has posted a patch implementing the "dirsync" option on the ext2 and ext3 filesystems.

• Neil Brown has posted his linux.conf.au paper on the future of authentication in the kernel NFS daemon.

Kernel building:

• Anuradha Ratnaweera has the release of kernelconf 0.1.3. See if you would like to know where to actually get the code.

Miscellaneous:

• Denis Vlasenko has posted a new list of kernel maintainers.

• has been released by Thomas Capricelli. Zeta is a port of Linux to a virtual platform, done as an exercise in learning the internals of the system.

• James Bottomley has a new version of his port to the NCR Voyager architecture.

• Kernel Traffic for February 11 is available.

Section Editor: Jonathan Corbet

For other kernel news, see: Kernel traffic Kernel Newsflash Kernel Trap 2.5 Status

Other resources: L-K mailing list FAQ Linux-MM Linux Scalability Effort Kernel Newbies Linux Device Drivers

Next: Distributions