See also: last week's Kernel page.

Kernel development

One of those tweaks, unfortunately, was a parallel port change that fails to compile. As Linus said, "not a good week." In the same message, he also put out this teaser:

On the other hand, the good news is that I'll open 2.5.x RSN, just because Alan is so much better at maintaining things ;)

As of this writing, 2.5 still does not exist. There also is no 2.4.13; Linus evidently decided to take a more deliberate pace with the next release. Those wanting to build 2.4.12 should apply the fix for the parallel port problem first.

2.4.12 also has a problem in the disk partition code that can cause partitions to disappear. There is a fix available for that problem as well

Alternatively, of course, there is the latest prepatch: 2.4.13-pre4. It contains those fixes along with several others, and "continued merging" from the "ac" series.

Speaking of which, Alan Cox's latest is 2.4.12-ac3. It contains a much-awaited ext3 filesystem update, a bunch of ARM fixes, and many other tweaks and updates.

Tidbits from the VM front. The question was asked this week: why is Andrea Arcangeli's "simple" virtual memory implementation in the Linus tree? Linus had a straightforward answer:

The benchmarks I've seen says that the simple VM performs better - both in terms of repeatability and in terms of absolute performance.

Alan Cox, meanwhile, says that he has "not reached any final conclusions on the VM." He is apparently still waiting to see how things settle out before deciding which implementation he wants to go with. Given that he is the "maintainer apparent" for 2.4 in the near future, his decision will be important.

Rik van Riel continues to work in his implementation for the "ac" tree; his latest patch has generated some positive reviews.

Randy Hron has published the results of some performance testing on a few VM implementations. The testing involved running a Linux Test Project utility to allocate most of the available virtual memory, while simultaneously playing music out his sound card. Some of his findings:

• 2.4.12-ac1 ran quickly, with a great deal of variation in the amount of memory that was able to be allocated.
• 2.4.12-aa1, using a patch from Andrea Arcangeli, provided the best performance of all, with the most pleasant music listening experience as well.
• 2.4.13-pre2 locked up partway through the test.

Conclusions are hard to draw at this point. Both 2.4 virtual memory implementations are improving under the pressure of the competition between the two trees. At some point, this issue will have to be resolved; in the mean time, more hacking and benchmarking appears to be called for.

Modules, symbols, and licenses. There has been a scattered report or two of module loads failing in recent kernels due to conflicts with GPL-only symbols. These are actually a little surprising; the 2.4.12 kernel supports the EXPORT_SYMBOL_GPL macro, but no symbols are yet exported in this mode. The real problems are almost certainly elsewhere; the module loading code is just trying to be helpful by pointing out, when loading non-GPL modules, that the license may be the problem.

The other half of that problem is that not all GPL-licensed modules have yet been fixed up with the appropriate MODULE_LICENSE tags. Thus causing the GPL complaint when loading the loop driver code, which is part of the kernel and has been covered by its license since 1993. A truly stable kernel would not have glitches of this variety, but....

A different change is coming in 2.5. Way back in 2.0, any symbols (variables) defined within a module would (1) be available for setting by the user at module load time, and (2) be exported to the rest of the kernel. In 2.2, load-time variables were tightened up; only variables which were explicitly designated can be changed when loading the module. But, unless the module declares explicitly to the contrary, all global symbols in the module will still be exported to the kernel.

In 2.5, that will change; no symbols will be exported without explicit instructions to that effect. The module code is going to be more restrictive than that, however: if a module does not state its intention with regard to symbols one way or another, the system will refuse to load it. In the words of Keith Owens, the perpetrator of this change, "That will break a lot of modules."

The fix for broken modules is usually easy. Very few kernel modules actually need to export symbols to the rest of the kernel; simply adding an EXPORT_NO_SYMBOLS line will make that explicit and allow the module to be loaded. There are those who would rather see EXPORT_NO_SYMBOLS simply become the default, avoiding the need to edit large numbers of modules. Keith's reasoning for requiring the change is to force somebody to actually look at each module and see what its symbol needs really are.

Other patches and updates released this week include:

• Riley Williams has been digging through the release history of several prominent kernels. For the curious, here's the step-by-step history for 1.0.9, 1.2.13, and 2.0.39.

• Jacques Gelinas has released a patch which allows a Linux system to function as several independent virtual servers.

• kdb 1.9 for the 2.4.12 kernel was released by Keith Owens.

• Greg Kroah-Hartman has released a new version of his Compaq hotplug PCI driver.

• Also from Greg is dietHotplug 0.2, a thinned-down implementation of the hotplug code.

• The latest preemptible kernel patch is available from Robert Love.

• Jeff Dike has released User-mode Linux 0.49-2.4.12.

• The Haifa Linux Club has released syscalltrack-0.63, a tool for monitoring and acting on system calls.

• Release 1.0.8 of IBM's Journaling Filesystem was announced by Steve Best.

• Version 0.7.21b of the access control list code has been released by Andreas Gruenbacher. Note that the system call numbers have changed, so users of this patch will need to rebuild their utilities.

• "Nemosoft" has released a new Phillips Webcam driver; this driver already appears in the "ac" kernels.

• Alexander Viro has posted a patch which would make it easier for kernel code to offer large "files" via /proc. Currently, the handling of large amounts of /proc output is done in an ad hoc and often buggy manner; the new interface offers a set of support functions to make this task easier. (People wanting to actually try the patch will want to look at the updated version).

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