See also: last week's Kernel page.

Kernel development

2.3.99-pre9 also contains the results of continued work on the memory management problems that have afflicted recent kernels. Progress has been made - 2.3.99-pre9 is far more responsive than 2.3.99-pre8 was. There are still complaints about poor I/O behavior, however; some work remains to be done.

A 2.3.99-pre10 preprepatch is available, in its third revision as of this writing. It contains a pair of drivers from H. Peter Anvin that provide access to the x86 "model specific registers" and CPUID information, a SiS 300/630/540 frame buffer driver, and some Sparc tweaks.

Alan Cox posted a new 2.4 jobs list on May 25.

The current stable kernel release is 2.2.15. The 2.2.16 prepatch is at 2.2.16pre4. There is currently no word on when the official 2.2.16 release might come out - it will probably be a while yet.

Eric Raymond hacks up a new kernel configuration scheme. The Linux kernel is a complicated beast, with a great many different ways in which it can be built. Anybody who has ever built their own kernel has had to deal with the kernel configuration mechanism (kbuild), which deals with all of these options. This mechanism selects which capabilities are to be built into the kernel, handles dependencies (i.e. no ethernet cards if the kernel isn't built with networking), and presents three different interfaces (command line, curses, and X) to the user. Kbuild, in handling all these tasks, has evolved into a complicated piece of code in its own right.

It's also a twisted mess of shell scripts, Tcl/Tk scripts, awk scripts, perl, and C code. It's hard to maintain, hard to understand, and unable to be adapted to meet the user interface needs of a large number of Linux users. Not everybody really wants to plow through many hundreds of individual, detailed configuration options, after all. Eric Raymond tried to do some of this interface work back in March, and finally posted a frustrated message to the linux-kbuild list in which he said:

I've been examining the existing kernel configuration system, and I have about concluded that the best favor we could do everybody involved with it is to take it out behind the barn and shoot it through the head.

Eric, of course, is well equipped to do exactly that.

The very same day, long-time kbuild maintainer Michael Elizabeth Chastain posted a note saying that he could no longer keep up with maintaining the system; a new maintainer was requested.

Quite a bit of discussion followed, but absolutely nobody spoke in favor of retaining the existing code. So Eric went off to start hacking on a new kbuild system. On May 24, he released the new implementation, which he calls "CML2." CML2 is a new "mini-language" which is designed for the specific task of configuring kernels. A "ruleset" is written in CML2 which describes all of the available kernel options and their dependencies; a compiler is then run on the ruleset to create the "rulebase." Any of a number of configuration front ends can then read this rulebase and use it to configure a kernel.

The CML2 language has a number of advantages, not the least of which is that it was designed as a coherent whole, rather than slowly growing into a big mess. It is claimed to be more expressive; the 7000+ lines of old configuration code are reduced to 2400 lines of CML2, though one should also probably count the almost 2000 lines of CML symbol definitions which define the various options.

The new scheme also makes a clear distinction between the configuration language and the user interface, allowing the two to be developed independently.

Eric's hope is to get people playing with the new system now, with an eye toward inclusion in the 2.5 development series. It can coexist with the current kbuild system, and, as has been noted, the current scheme has few defenders. Thus, if CML2 works, one might anticipate that it would be adopted with little trouble. The one sticking point may be that it's written in Python; not everybody wants to have to keep a Python system around.

Thinking toward the future. A number of people posted articles on possible future developments this week. They include:

• Guus Sliepen proposed the creation of a suite of kernel benchmarking tools. The need is clear: much work, such as recent efforts with memory management, has been hampered by the lack of a way to objectively measure the results.

• Jeff Garzik would like to see an organized set of changelogs for the kernel, so that people actually know what is going in with the patches. The idea makes sense, but it would essentially require that Linus maintain the log on top of everything else that he does; he has not been enthusiastic about that idea in the past.

• Rik van Riel has come up with a new memory balancing scheme which, he hopes, is the path forward to better memory performance in the future.

• Neil Brown's posting from last week on the devfs issue drew a number of responses. James Feeney wrote about how he would like to see a dynamic device file system work. Jason McMullan chimed in with a call for a strong push toward the "everything is a file" view of the system; Ted Ts'o responded with reasons why some things should not be files.

Other patches and updates released this week include:

• Rick van Rein updated his "BadRAM" patch, which enables the kernel to use defective memory by avoiding the bad parts.

• A patch which provides directory notification (sending a message to interested processes when a directory changes) was posted. See also Ted Ts'o's response on the limitations that apply to notification.

• Ted Ts'o posted a serial driver update that fixes a number of issues and supports some new hardware.

• Trond Myklebust posted a new version of the NFSv3 client code for the 2.2.15 kernel.

• Version 1.2 of the performance monitoring counters driver was released by Mikael Pettersson.

• Alan Cox has released a set of Red Hat kernels with USB and ext3 support built in.

• Brad Hards has announced the availability of version 1.0.9 of the Linux USB Guide.

Section Editor: Jonathan Corbet

For other kernel news, see: Kernel traffic Kernel Newsflash Kernel Trap Linux 2.5.x Porting help

Other resources: Kernel Source Reference L-K mailing list FAQ Linux-MM Linux Scalability Effort Kernel Newbies Linux Device Drivers

Next: Distributions