See also: last week's Kernel page.

Kernel development

• The ext3 filesystem has been merged; as of 2.4.15, the mainline kernel will have two journaling filesystems available. It's marked "experimental," of course, but it's a start. As part of the ext3 merge, the kernel now has a "journal block device" module which is intended to provide a generic journaling layer usable by any filesystem.

• The changelog does not mention it, but another goodie that has been included is the InterMezzo filesystem. InterMezzo is a high-availability, distributed filesystem, with the usual nice features (caching, disconnected operation, failover, etc.).

There are no "ac" patches for now; Alan has been working on merging his stuff into 2.4.15 instead.

Coding style in the kernel. Code style is one of those issues that programmers can argue over indefinitely. So, in a sense, it's surprising that the Linux kernel list sees very few discussions on this matter. Most of the time, kernel hackers are more concerned about the quality of the code, rather than what it looks like.

Thus, a look through the kernel source will turn up a number of different ways of formatting code - especially in peripheral pieces like drivers. There is an official coding style for the kernel, though, as set down (in typical Linus style) in the CodingStyle document found in the source tarball. It's introduced in this way:

This is a short document describing the preferred coding style for the linux kernel. Coding style is very personal, and I won't _force_ my views on anybody, but this is what goes for anything that I have to be able to maintain, and I'd prefer it for most other things too. Please at least consider the points made here.

First off, I'd suggest printing out a copy of the GNU coding standards, and NOT read it. Burn them, it's a great symbolic gesture.

If you want to start a debate on a subject, however, all that seems to be necessary is to involve perennial target Richard Gooch. A number of developers have gone after him for not following the Linus-blessed coding style. The argument, essentially, is that, since Richard's code is part of the core kernel, it should adhere more closely to the coding standards. Numerous other developers need to look at this code, they say, and they have a harder time of it as a result of the different style.

Richard's response is that it's his code, and, as long as he's maintaining it, he should be able to use a style that allows him to work efficiently:

And the coding style used elsewhere in the kernel is revolting to me. More importantly, it's harder for me to parse than my own style. I shouldn't have to constantly stumble over an appalling coding style in my own code!

Some kernel hackers could get away with this approach, but Richard is running into resistance. One person even submitted a patch reformatting one of Richard's subsystems into the standard style. Linus didn't accept it - among other things, he doesn't want to be doing that sort of tweaking at this particular point in the stable kernel series.

If a certain subset of hackers has its way, however, coding standards will be more of a concern with future changes to the kernel. Most large projects do have such standards, and maybe it's time for the kernel to follow suit. It would be a change in the kernel development environment, which has always prized the independence of its hackers, however.

Are loadable modules free? The question was raised: what sort of speed difference is seen when using loadable modules instead of hard-linked code? The immediate response from some was "almost nothing," but further consideration has shown that not to be true. There are, in fact, a number of costs associated with loadable modules.

The biggest, perhaps, relates to how loadable modules are placed in kernel memory. The code for a module needs to live in a contiguous address space. The kernel sets up that address space with a function called vmalloc, which allocates memory with virtual addresses. In other words, a loadable module is in an address space that is visible to the kernel, but which is separate from where the core kernel code goes.

This difference is important. The core kernel address space is a direct map of physical memory; it can be handled very efficiently in the processor's page table. Indeed, on some processors, a single page table entry covers the entire kernel. Space obtained from vmalloc, instead, uses one page table entry per memory page. A greater number of page table entries means more lookups, and more translation buffer misses. One estimate is that the slowdown can be as much as 5%.

Given this problem, why not load modules into the regular kernel memory space? Module code requires a contiguous address space. Since the standard kernel space is a direct map of physical memory, contiguous address spaces must also be contiguous in physical memory. Once the system has been running for a while, finding even two physically contiguous pages can be a challenge; finding enough to load a large module can be almost impossible.

Nonetheless, it turns out that Andrea Arcangeli's kernel patches include a feature where the kernel will attempt to find a contiguous space for an incoming module. If that attempt fails, the kernel falls back to the older vmalloc approach. This change, it is said, makes a measurable difference with some benchmarks.

Some architectures (i.e. PowerPC) also have problems going between kernel and module code. There can be a substantial amount of setup work required every time that transition happens.

Modules also seem to have endemic problems with race conditions - it is possible, for example, for the kernel to attempt to access a newly-loaded module before it is fully initialized. Modules can also, in some situations, be removed while still in use. Such occurrences are obviously quite rare, but they can be catastrophic when they happen.

The race conditions can be fixed with enough work, but that may require changing some fundamental kernel interfaces. In general, dealing with loadable modules is not an easy task; as one kernel hacker told us in a private message: "Doing live surgery on the kernel is never going to be pretty."

Warning about GPLONLY symbols. A little while back, the ability to reserve kernel symbols for GPL-licensed modules only was implemented. An attempt to load a non-GPL module yields an "unresolved symbols" complaint, along with the message: "Note: modules without a GPL compatible license cannot use GPLONLY_ symbols." This message has, apparently, created a certain amount of user confusion, so the next version of modutils will, instead, say something like:

Hint: You are trying to load a module without a GPL compatible license and it has unresolved symbols. The module may be trying to access GPLONLY symbols but the problem is more likely to be a coding or user error. Contact the module supplier for assistance.

This seems like a step in the right direction, but it raises an obvious question: why not simply distinguish between the two different errors and tell the user exactly what's going on? There is no real reason to tell users about GPL-only symbols if the module in question is not trying to use any of them.

The answer is that it's just too much trouble, for now. The modutils symbol code is getting messy; it will be fixed in 2.5, but, for now, the above message is the best that can be done. Besides, says modutils maintainer Keith Owens, "Since it only affects BOMs [binary-only modules], I don't really care that much about precise error messages."

Other patches and updates released this week include:

• Ingo Molnar has posted a scheduler patch which works to keep processes running on the same CPU.

• Release 1.6 of the 2.5 kernel build system is available from Keith Owens.

• Version 1.0.9 of the Journaling Filesystem has been announced by Steve Best.

• Linux-NTFS 1.4.0 has been released by Anton Altaparmakov.

• Keith Owens has released modutils 2.4.11.

• Andi Kleen has announced the release of a new snapshot of the X86-64 kernel tree.

• FUSE (Filesystem in USErspace) is a patch, released by Miklos Szeredi, that provides an interface for the creation of filesystems in user space. It does appear to be an easy interface to work with - a Python interface has already been posted.

• IBM has released version 3.1 of its Dynamic Probes kernel debugging facility.

• Robert Love has released a new preemptible kernel patch; the main change this time around is support for the ARM architecture.

• Richard Gooch has updated his new devfs core implementation.

• Now that 2.5 appears imminent, Eric Raymond has started putting out new releases of the CML2 configuration system.

• Version 0.51-2.4.14 of the User-mode Linux implementation was announced by Jeff Dike.

• Nick Bellinger has posted an implementation of the Openwall SECURE_LINK capability using the security module framework.

• A new AX.25 release was announced by Jens David, who has also announced that he will no longer be maintaining that project.

• Version 0.7.23 of the access control list implementation for Linux was posted by Andreas Gruenbacher.

• The first public netlink interface for netfilter has been announced by J. Schulist.

• Ben Collins has released version 1.2.4 of SILO, the Sparc boot loader.

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