Kernel development

Kernel release status

The current development kernel is 2.5.41, which was released by Linus on October 7. "Mucho merges with the 'A-Team' (Alan, Al, Alexey, Andrew, Anton, Arjan, Arnaldo and Art), but the 'M-Team' (Maksim, Marcel, Martin's and Mike) is a close runner up." There's a bunch of patches from Alan Cox, more disk management reworking, more memory management work, some SCSI work, a big ALSA update, an ISDN update, some kbuild work, a big S390 update, and numerous other fixes. The long-format changelog has all the details.

Linus's BitKeeper repository, which is destined to become 2.5.42, currently contains some driver model work (with an emphasis on IDE devices), another s390 update, the large block device patch (see below), the beginning of the "asynchronous I/O for networking" merge, the return of IDE tagged command queueing support, indexed directories for the ext3 filesystem, a number of NUMA and discontiguous memory enhancements, long lists of small patches via Dave Jones and Alan Cox, and quite a few other fixes and updates.

The current development prepatch from Alan Cox is 2.5.41-ac2. Since 2.5.41 came out, the -ac patches have been mostly concerned with compilation fixes and other small updates.

The latest 2.5 status summary from Guillaume Boissiere is dated October 9.

The current stable kernel is 2.4.19. Marcelo released 2.4.20-pre10 on October 8. The lists of patches applied are getting smaller, suggesting that there just might be a release candidate before too long.

Comments (none posted)

A new way to watch Linus

The lengthy BitKeeper flame war was not entirely without useful results. Some developers expressed a wish to have a better view into what patches were being applied without having to run BitKeeper to extract them; the response was the creation of a couple of "bk commits" mailing lists on vger.kernel.org. Every time Linus merges a patch, the "bk-commits-head" list gets a message containing that patch. A similar list (bk-commits-24) exists for those who want to track what's up with the 2.4 kernel instead. Now there's no excuse for not knowing what got merged into 2.5 ten minutes ago.

See the vger majordomo page for information on how to subscribe to these lists.

Comments (none posted)

Unexporting the system call table

A linux-kernel reader recently complained that Red Hat had applied a patch to the kernel in its 8.0 distribution which made the sys_call_table data structure unavailable to modules. He will not have been pleased with the 2.5.41 kernel release, which did the same thing.

sys_call_table is a special table used to dispatch system calls within the kernel. It is a simple array, indexed by the system call number passed in from user space. The reason for wanting this array to be exported, of course, is to allow modules to add or modify system calls. A classic example is a module implementing the "streams" interface, which is unlikely to ever be part of the mainline kernel. Some users need streams, though; an exported system call table allows them to load a module and have the streams call work as expected.

So why would this capability be taken away? The stated reason is that tweaking the system call table is nonportable and unsafe. Each architecture has a different system call table format, so code which wants to be portable has to understand how each architecture does things. There is also no locking mechanism for the system call table, so run-time changes are subject to race conditions. And finally, there are even errata problems on some processors; changing a table used the way sys_call_table is used can have unfortunate and unexpected results.

Many of these problems could be worked around with a bit of coding. But the simple fact is that many kernel developers do not want loadable modules to be able to add or change system calls. Binary modules are tolerated as long as they stick to the "published" interfaces and implement straightforward features (such as device drivers and filesystems). A module which can add or change system calls can go well beyond that interface. Removing access to the system call table keeps modules in their place.

Working around this problem not all that difficult for modules which need to do so. A patch was quickly posted which made streams work again, for example. The solution is to have a set of stub system calls wired into the kernel; when the associated module is loaded, the stubs can make the appropriate calls with the necessary locks. Otherwise they return an ENOSYS error.

Comments (none posted)

A different new Linux configuration scheme

One would think that, after Eric Raymond's experience with trying to overhaul the kernel configuration scheme, nobody else would want to venture into that area for a long time. One would be wrong, however; Roman Zippel has been working on his "LinuxKernelConf" package for some time, and has recently posted version 0.8, with a statement that it is ready for inclusion.

LinuxKernelConf, like the ill-fated CML2 effort, defines a new configuration language (specification) and creates a single parser that can be used by all configuration interfaces. The new language is purely declarative, unlike the old one, which was really an imperative programming language. A configuration file (there are now many, spread throughout the source tree) contains declarations for the various configuration options, including all the relevant information in one place. A typical entry looks something like this:

config NETFILTER_DEBUG
        bool "Network packet filtering debugging"
        depends NETFILTER
        help
        You can say Y here if you want to get additional 
	messages useful in debugging the netfilter code.

Note that, among other things, this scheme includes the help information with the rest of the configuration details.

Unlike CML2, Mr. Zippel's scheme avoids fancier scripting languages and works with basic tools. That will help to avoid one set of flame wars. LinuxKernelConf may well stumble over a different obstacle, however: the (quite nice) graphical configuration tool is built on Qt. That is, in fact, the source of Linus's biggest concern about this patch:

In fact, there have been very few death threats so far, perhaps because not too many people have looked at the code. Regardless of the level of promised violence, however, it looks like LinuxKernelConf may be merged with some evasive action: the graphical interface will simply be omitted. The kernel will thus ship with the basic configuration language; anybody who wants to use a graphical tool will need to obtain and install it separately. One a few other, smaller issues are resolved, it looks like Linus may go ahead and merge this patch.

Comments (4 posted)

Breaking the 2TB barrier

One set of patches which Linus has merged into his pre-2.5.42 BitKeeper tree is the "large block device" patch by Peter Chubb. Current Linux systems are limited to a mere 2TB in any one block device; this limitation is beginning to hurt users of very large RAID arrays. With the LBD patch, that limitation goes away.

The solution, of course, is to simply redefine the sector_t type as a 64-bit quantity. Mr. Chubb's patches (which can be found in the "patches" section below) do exactly that. Generally, the transition is not that hard; the bulk of the changes, seemingly, are to format strings in printk calls. Much of the rest is changing variables which were defined as int or long over to the sector_t type.

For the most part, it is said to work. Note, however, that software RAID volumes are still limited to 2TB.

Comments (none posted)