See also: last week's Kernel page.

Kernel development

The latest prepatch from Dave Jones is 2.5.5-dj2; it is caught up with 2.5.6-pre1 and 2.4.19-pre1, and adds a number of other small fixes.

The February 27 version of Guillaume Boissiere's 2.5 Status document is available.

The current stable kernel release is 2.4.18, which was released on February 25. It was intended to be identical to the 2.4.18-rc4 release candidate; unfortunately, a slip of the fingers caused the one -rc4 patch to be dropped from the final release. The result is that static applications on a few architectures will not work properly. There was a great deal of discussion on what should be done, but the consensus seems to be that the problem is not that severe. Thus there will not be a replacement 2.4.18 patch, or an expedited 2.4.19.

The 2.4.19 process has begun with 2.4.19-pre1, which adds a rather larger set of fixes, but no real new features.

Alan Cox has a couple of prepatches out there. 2.4.18-ac2 adds a small number of fixes to the 2.4.18 kernel. 2.4.19-pre1-ac2 brings in more stuff, including the USB 2.0 implementation and a number of hotplug support patches.

On the 2.2 front, Alan has released 2.2.21-pre3 which adds another long set of fixes.

Pressure to add new features to 2.4 is growing. Thus far, Marcelo has held a firm line with his 2.4 kernels: almost everything that goes in is a fix for some problem or other. As time goes by, however, there is an increasing number of requests for the merging new features and more intrusive changes. Recently there have been requests for new filesystems (XFS, JFS), USB 2.0, the reverse mapping VM (Rik is not ready to see that merged yet, though he has submitted the portion that shrinks struct page), the new scheduler, the SD many patch, and more. The era of bugfix-only 2.4 releases may be coming to an end.

This situation poses a bit of a challenge to Marcelo. If larger patches start to go into 2.4, chances are that new bugs will be introduced. Now that 2.4 is finally getting truly stable, few people would like to see it be destabilized again. On the other hand, the 2.6/3.0 kernel could well still be two years away; it is unrealistic to expect that 2.4 will stand still for that long. If Marcelo does not release kernels with, at least, the more obvious and safe improvements, somebody else will.

So expect the 2.4 releases to get more interesting. With luck and proper care, they hopefully won't get too interesting...

The proper way to migrate processes. The new scheduler code in the 2.5 series implements, among many other things, per-CPU run queues. Processes normally stay in the same queue, and run on the same processor; there are a number of performance benefits to doing things this way. Occasionally, however, it is necessary to move a process to another CPU; this move can happen as a result of load balancing (fixing a situation where one processor is switching between many tasks while another sits idle), or from an explicit user-space request.

The 2.5.5 scheduler only allows the current process to be migrated to another CPU - essentially, processes must move themselves. This limitation gets in the way of a number of possible applications; it is often desirable to move arbitrary processes around as the result of user-space decisions. So a few people have been working on ways to relax the "current process only" constraint.

Erich Focht posted a patch which implements a "migration interrupt." When a process is to be moved, the target processor is interrupted; it waits until the process is in a movable state, then performs the required operations.

The problem with this approach is that the target processor must wait in the interrupt handler for things to happen - never a good way to do things. If the target processor holds a resource (a spinlock, say) that the process to be moved requires, a deadlock could result. So Ingo Molnar has posted a patch of his own which takes a different approach; this patch was included into the 2.5.6-pre1 prepatch.

The new code works by setting up (yet another) kernel thread on each processor dedicated to the process migration task. When a process is to be moved, it is put onto a queue and the appropriate migration task is awakened. That task can wait for the process to become movable; since it is just running as another process, it can afford to wait as long as necessary (by giving up the CPU) without running the risk of deadlocks. It looks like a scheme that should work well, but expect a round of "what are those migration_CPU* processes?" questions after 2.5.6 comes out.

Doing the BK Thing, Penguin-Style. Jeff Garzik has posted a document on how to do kernel development using BitKeeper. Since Linus's use of BitKeeper is increasingly looking like a permanent thing, this document is recommended reading for anybody who submits patches (even though use of BK is not required).

On the developer's end, this also represents a fundamental disruption in the standard workflow of changes, commits, and merges. You will need to take a few minutes to think about how to best work under BitKeeper, and re-optimize things a bit. In some sense it is a bit radical, because it might described as tossing changes out into a maelstrom and having them them magically land at the right destination... but I'm getting ahead of myself.

Have a look for the complete story.

Other patches and updates released this week include:

Core kernel code:

• Michael Sinz has posted a new version of his patch allowing the names of core dump files to be customized on a per-process basis.

• Mike Kravetz has posted a scheduler for NUMA systems which attempts to address the issues unique to that sort of platform. (The patch has since been updated).

• Erich Focht has a NUMA patch of his own which takes a bit of a different approach.

• Rik van Riel has released version 12g of his reverse mapping VM implementation.

• The February 25 Linux security module patch is available. Among other things, it includes support for the Linux Intrusion Detection System.

Development tools:

• Dan Aloni posted for the Linux kernel. The response has not been terribly positive...

• Syscalltrack 0.7 was released by Guy Keren.

• Keith Owens has released for the 2.4.18 kernel.

Device drivers

• David Miller and Jeff Garzik have released a new Broadcom Tigon3 driver. "It is meant to replace Broadcom's driver because frankly their driver is junk and would never be accepted into the tree." (The latest version is 0.92).

Filesystems:

• UVFS 0.5, a user-space filesystem implementation, was released by Britt Park.

Miscellaneous:

• Keith Owens has released modutils 2.4.14.

Networking:

• Version 0.93 of the Affix BlueTooth stack has been announced by Dmitry Kasatkin.

• Version 2.4.17-0.4.4 of the Linux SCTP implementation has ben announced by Jon Grimm.

• The iptstate tool has been released by Phil Dibowitz. "Based on the idea of IP Filter's 'statetop' feature, IP Tables State displays states in your firewall in a top-like format, in real-time."

Ports:

• James Bottomley has updated his patch for the NCR Voyager architecture.

• Robert Schwebel has released a new version of his AMD Elan patch.

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