Zack's Kernel News



The Linux kernel mailing list comprises the core of Linux development activities. Traffic volumes are immense, often reaching ten thousand messages in a given week, and keeping up to date with the entire scope of development is a virtually impossible task for one person. One of the few brave souls to take on this task is Zack Brown.

Our regular monthly column keeps you abreast of the latest discussions and decisions, selected and summarized by Zack. Zack has been publishing a weekly online digest, the Kernel Traffic newsletter for over five years now. Even reading Kernel Traffic alone can be a time consuming task.

Linux Magazine now provides you with the quintessence of Linux Kernel activities, straight from the horse's mouth.

Device Driver Developer Kit

Greg Kroah-Hartman, in conjunction with FreedomHEC, has put together a fully GPLed device driver developer's kit http://kernel.org/pub/linux/kernel/people/gregkh/ddk/.

The kit is a CD image containing tons of documentation, including the in-kernel DocBook docs and a full copy of "Linux Device Drivers, 3rd ed," as well as the kernel sources themselves. In future versions, Greg plans to create a searchable index, a more stylish web interface, and additional documentation.

The project received raucus applause from prominent kernel folks, and there was much offering of suggestions for future releases. While there have been earlier efforts aimed at helping developers, this tool aims to gather the best of those efforts together and present them in a consistent and accessible way. Given the mass of tools available for device driver development on other operating systems, Greg's work comes none too soon.

New AXFS Filesystem for Embedded Systems

Jared Hulbert has produced a very preliminary version of AXFS (Advanced XIP File System). Intended as a read-only root filesystem for embedded devices, AXFS uses XIP (eXecute In Place), so programs are run directly from their location in non-volatile storage instead of being loaded into RAM. This turns out to be somewhat controversial, since RAM is presumably faster and cheaper than the non-volatile storage actually used.

Jared proposes a couple defenses of the XIP approach. The first is cost. Storing a binary executable as a compressed file in Flash, and then uncompressing it into RAM, uses more overall resources than just storing it uncompressed in Flash and running it right there. There may also be speed benefits, as it could be quicker to start a program that way than to first go through the process of uncompressing it and copying it to RAM.

AXFS has so far gotten a mixed reaction. On the one hand, it is not yet fully usable. Jared posted his preliminary work so as to make sure the direction of development met with the kernel community's approval. But this leaves little room for testers and users to actually judge the filesystem. Jared has also not done much performance testing, so AXFS is difficult to compare to other alternatives. AXFS is intended to run on Linux-based cell-phones, but Jared is not yet able to disclose which phones these are.

In spite of the above, a number of kernel folks, including Mark Lord of IDE fame, seem quite impressed with the work so far, and AXFS has generated a lot of technical comments and suggestions, which usually indicates that something is at least interesting enough to consider. Mark in particular said that he had several embedded systems clients that could make use of AXFS right away. But Jared was quick to reiterate that this is just a preliminary release, not at all ready for a "production" system.

Raising Some Hard-Coded Limits

More and more folks have been hitting the five-nested-link limit on symbolic links. Recently Brian D. McGrew had enough of it and asked how he could adjust this in his own source tree. H. Peter Anvin suggested making it runtime configurable; but Alexander Viro said it was high time to raise the limit to eight nested links, as he'd said he would do back in February.

He posted a patch to accomplish this, but Andrew Morton was ambivalent. Andrew pointed out that the change would not be backwards-compatible, and software taking advantage of the eight-nest limit would be unable to run on older systems. On the other hand, if the change had to be made, it might as well be now, in the 2.6.17 cycle, since most distributions are 2.6.16-based and would not be immediately broken. And as Arjan van de Ven and Alan Cox pointed out, several major distributions including Red Hat had already made the switch on their own.

In a similar vein, Randy Dunlap recently posted a patch to raise the limit of hostname lengths from 64 characters to 255 to be compliant with POSIX. While this change was less controversial than the nested-symbolic-link patch, there was some confusion until it was pointed out that Linux had actually been noncompliant until now. Jan Engelhardt pointed out that at least Linux's noncompliance had forced applications to be flexible enough to deal with it.

Experimental Code and the Experimental Tag

Chris Wedgwood has gone over a few drivers marked "EXPERIMENTAL" and submitted patches to make them first-class kernel features. One of these is the EDD feature, allowing BIOS Enhanced disk drives to determine which disk to boot from at run-time.

He also marked the oprofile kernel profiling feature as no longer experimental. This case was trickier, as oprofile is not maintained, and there have been reports of problems. Typically, if a kernel feature has no maintainer, it is deprecated and then removed. But since so many people, including Alan Cox, find oprofile extremely useful, this option doesn't seem to have much appeal. Even Chris, who had initially proposed deprecating it, uses and likes oprofile himself. The oprofile conversation ended inconclusively.

Chris also marked REGPARM as no longer experimental. This is a deep kernel feature that provides a speed-up by allowing code to assign function arguments to CPU registers, rather than having to push the arguments onto the stack in all cases. As it turned out, not only could REGPARM be taken off the `experimental' list, but there was no need to have it be optional at all. The kernel had come to depend upon it, and it generated better code than the older alternative. So Chris made a new patch to make REGPARM just a part of the kernel and not an option.

Finally, an interesting tidbit came out of the oprofile discussion. The question arose, "what does `experimental' actually mean?" Apparently, it is open to a wide array of interpretations, and developers have been marking features as experimental when they work well, when they are temporarily broken, when they are dangerous to use, and so on. At one point Chris himself said that he'd come to feel the "EXPERIMENTAL" tag was essentially pointless, as it hides too many useful features, and every developer appears to have their own interpretation of when it is appropriate to use.

Status of Linux 2.4

Recently I wrote that the 2.4 tree had gone into "deep maintenance mode," with no more drivers being backported from 2.6; and that this meant there was not really a "stable" tree anymore, given that 2.6 was still under hot development.

The situation has not changed, but Marcelo Tosatti recently released Linux 2.4.33-pre3 after a long silence, with over a dozen patches applied, just a drop in the bucked compared with the hundreds that usually go into a 2.6 release. Most of the 2.4.33-pre3 patches are security fixes, but one patch corrected a missing license for the quota_v2 module.

This latest update from Marcelo confirms the status of 2.4 as no longer accepting any but the most crucial fixes. Andi Kleen, David S. Miller, Willy Tarreau, Craig Brind, Hugh Dickins, Jeff Layton, Jesse Brandeburg, Marek Szuba, Marin Mitov, Mika Kukkonen, Pavel Kankovsky, Stefan W. Hahn, and Stephen Rothwell all had patches accepted into this release.