Linux in the news
All in one big page
See also: last week's Kernel page.
The current development kernel release is 2.5.4, which was released on February 11. The biggest news, of course, is the inclusion of the preemptible kernel patch. This release also has the delightful feature that it fails to compile for many users. There have been no 2.5.5 prepatches as of this writing.
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 2.5.4-dj1, which adds a number of fixes to the 2.5.4 release. This one should compile for most people.
Guillaume Boissiere's 2.5 status summary 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 the word from Linus:
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 a patch 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:
Section Editor: Jonathan Corbet
February 14, 2002