See also: last week's Kernel page.

Kernel development

The current kernel release is still 2.4.14. Linus's prepatch series is up to 2.4.15-pre7. Very little beyond basic bugfixes has been added to the prepatch in the last week; it appears to be stabilizing. The 2.4.15 kernel may have been released by the time you read this.

Where are the "ac" patches? One user asked when Alan Cox would resume making patches that tracked the 2.4.15-pre Linus tree. The answer would appear to be "not anytime soon." Quoted in full:

Right now I've fed all the stuff I feel makes sense to Linus for 2.4.15. Once 2.4.15 is out I'll send some more bits to Marcelo, and also some bits to Linus that are 2.5 material (eg PnPBIOS). The only "-ac" patch as such would be for 32bit quota and other oddments so I don't think its worth the effort.

Among such "oddments," of course, is the virtual memory implementation that the "ac" series has been using...

How synchronous should Linux be? One day, as Andrew Morton was wandering around the filesystem code, he noticed a seeming inconsistency. While Linux, like most operating systems that are concerned with performance, buffers filesystem writes in the kernels, it does provide a couple of ways for the user to request synchronous behavior:

• The "sync" option, used with the mount command, will request synchronous writes for every file in the filesystem.

• The chattr +S command can request synchronous updates for a single file or directory.

It turns out, though, that there are two types of opinion regarding synchronous writes of file data. Linux has never, in the past, had that behavior. The claim in the mount man page ("All I/O to the file system should be done synchronously.") is simply incorrect. Fully synchronous behavior is very expensive, leading to horrible performance, and is, according to some, rarely needed. It is better, according to this camp, to expect applications to use the fsync() system call to explicitly force synchronous behavior when it's needed in a specific situation. Rather than implement synchronous file writes, these folks (as typified by Stephen Tweedie) propose instead to limit implicit synchronous behavior to directories.

On the other side, Jeff Garzik argued that implementing synchronous file writes is the correct thing to do. Users sometimes need that behavior, and it is impractical to hack up applications and scripts to call fsync() explicitly. A separate dirsync mount option could provided to request synchronous semantics for directories only.

Amusingly, Andrew appears to have been won over by the first point of view, but his patch (implementing the second) found its way into 2.4.15-pre5. Unless something changes, fully synchronous behavior will be the way of things in 2.4.15.

Proposed feature: devlinks. Access to and naming of devices looks like it could be one of the truly divisive issues in 2.5 kernel development. The current system (static nodes in /dev using device numbers) is showing a few signs of strain:

• The static /dev directly is mismatched with the increasingly dynamic nature of hardware. Almost any type of peripheral can come and go without notice, but /dev just sits there.

• As more types of devices are supported by Linux, that static /dev directory has to hold more and more entries for hardware that might be present on somebody's system. /dev on a modern distribution can contain thousands of useless entries.

• The device number space is running out. Device numbers will be expanded in 2.5, but Linus is determined to move away from that scheme. For that reason, he is no longer allowing new major numbers to be assigned.

One solution to all of these problems, of course, is devfs, which is included in the 2.4 kernel. devfs is still not widely used, for a number of reasons. Its use requires non-trivial configuration changes, and the code contains some race conditions and locking bugs that are only now being sorted out. Its use also changes the way policy issues (device names and access permissions) are handled. The kernel can not remember (or guess) the permissions required for a particular device on a given system. This problem is handled with a user-space daemon, but not everybody likes that solution.

Neil Brown has come up with an interesting way of dealing with some of those issues. His proposal, implementing a feature called "devlinks," puts a static administrative layer in front of devfs, allowing a system administrator to set up system-specific policy while using devfs to get away from device numbers.

A devlink is essentially a new entry point into the devfs filesystem. The mechanism is a little clunky at the moment: the administrator creates a normal symbolic link, then types a magic mknod command that mutates it into a devlink. The devlink then acts as an access point to the devfs device. The crucial point, perhaps, is that the devfs filesystem itself need not be mounted. If devfs is left unmounted, devlinks become the only access path to the device. As such, they can be used to set permissions and device naming policy. And, since they are stored in a normal filesystem, they are persistent.

The devlink proposal does little for the handling of dynamic devices, and a directory full of devlinks could become just as cluttered as the current /dev. The proposal seems unlikely to get into the 2.5 kernel in its current form. But, as an attempt to work toward a solution to the device naming problems facing Linux, it is an interesting beginning.

Other patches and updates released this week include:

• Linux-ABI 2.4.14.0 was announced by Christoph Hellwig. This patch enables the kernel to support binaries built for a number of other operating systems.

• Richard Gooch has released devfs v197, the first full devfs release containing the new, reworked core code.

• Ben LaHaise has posted a new asynchronous I/O patch.

• A new multi-queue scheduler patch has been announced by Mike Kravetz.

• A release of the Scalable Test Platform for the 2.4.14 kernel has been announced.

• Andrew Morton has released a new version of his low-latency patch for 2.4.15-pre kernels.

• Jens Axboe has posted version 18 of his patch enabling DMA to block devices from high memory. This is the "prepare-for-inclusion" version of the patch.

• Jeff Merkey has announced a new version of the NetWare filesystem produced by Timpanogas. There are some doubts out there, however, as to just how Novell will react to this release, so caution is warranted.

• mconfig 0.20, a kernel configuration tool, was released by Christoph Hellwig.

• William Irwin has posted a new version of his tree-based boot memory allocator.

• Eric Raymond has released CML2 1.8.7.

• SGI has announced release 1.0.2 of its XFS filesystem.

• pcihpview, a graphical tool for working with hotplug PCI devices, was released by Greg Kroah-Hartman.

• Release 1.8 of the new kernel build system is out.

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