See also: last week's Kernel page.

Kernel development

The current stable kernel release remains 2.2.10. Alan Cox has a 2.2.10ac5 out there with a lot of good stuff. 2.2.11 is likely to come out shortly after the filesystem corruption problem is found, but...

The 2.2 filesystem corruption problem remains unsolved despite quite a bit of effort that has gone into tracking it down. There appear to be weak correlations between the problem and (1) overclocked systems, and (2) Adaptec controllers. However, neither is particularly strong, and a solution does not appear to be readily at hand. This is a difficult one, and certainly not much fun to have in a stable kernel.

The albods are coming. There is a continuing debate over whether Linux should provide a filesystem which provides a richer view of files. The discussion grew out of the idea of implementing "forked" files like the Macintosh does , or "streams" in files along the lines of Windows 2000. Last week we mentioned Hans Reiser's posting on the subject which claims that current filesystems are inadequate. According to Hans, any time that an application developer has to implement some sort of namespace, the file system has failed that developer.

Ted Ts'o responded with a strawman design for "application logical bundles of data" (or "albods") implemented entirely in user space. These "albods" had the advantages of working with any filesystem (even on a DOS diskette), of being transferable over FTP, and of requiring no kernel changes. His point was simply that such an approach is possible, so it is too soon to be thinking about hacking advanced namespace features into the kernel.

Transferability, via NFS, DOS diskettes, HTTP, or FTP, is a contentious issue. Many people are understandably nervous about changes that break all of those modes of moving files around. Hans replies that such people prove Bill Gates right: only Microsoft has the kind of centralized control that allows large, system-wide changes to be made.

The issue of implementing things in user space is also important. There is the (always contentious) issue of whether some desired feature belongs in the kernel - the Linux kernel is growing fast enough as it is. But another point is that a Linux kernel solution is probably a Linux-only solution. Application writers (such as those writing GNOME and KDE office suites) are much less likely to use a feature that is not portable across multiple systems.

This issue is far from any sort of resolution. Hans has stated his intention to hire somebody to implement his ideas, at which point there would at least be some code to argue about. (See also: Hans's Reiserfs web page that details a lot of what he is about).

A side discussion came up on the handling of filesystem flags. Alexander Viro proposed a new set of system calls for handling the specific attributes that would come with extended types of files. Stephen Tweedie pointed out that he had implemented a similar interface some time ago. And Linus chimed in on how it would work; his message indicates a certain amount of sympathy to the "albod" idea.

Various patches and updates released this week:

• The usual knfsd patch from H.J. Lu is out. He also threw in a set of init scripts that fix a problem with Red Hat 6.0.

• Devfs 112 from Richard Gooch, accompanied by devfsd 1.2.3.

• Michael Warfield announced a device driver for the Computone Intelliport II multiport serial card family.

• Willy Tarreau announced kmsgdump, a patch which causes kernel messages to be dumped out to a diskette. This patch may well be appreciated by those who have had the joyous experience of writing down an "oops" message by hand off the screen of a dead system.

Section Editor: Jon Corbet

For other kernel news, see: Kernelnotes Kernel traffic Kernel Newsflash

Next: Distributions