Linux in the news
All in one big page
See also: last week's Kernel page.
The current development kernel release is 2.5.7, which was released on March 18. This will be the last such release for a while, since Linus has headed off for a two-week vacation. This release contains some fairly big patches, including:
The latest from Dave Jones is 2.5.6-dj2, which adds a number of fixes and updates to the 2.5.7-pre2 kernel.
Guillaume Boissiere updated his 2.5 status summary on March 20.
The current stable kernel release is 2.4.18. The current 2.4.19 prepatch is 2.4.19-pre4; it includes a massive m68k update, the new video device code, and a great many other fixes.
Alan Cox's latest 2.4.19 patch is 2.4.19-pre3-ac4.
For those of you who aren't into all that bleeding-edge 2.4 stuff, David Weinehall has released 2.0.40-rc4 which should, with luck, turn into a real 2.0.40 soon.
Note that other kernel tree announcements now appear with the rest of the patches at the bottom of the page.
Kernel compilation benchmark update. When we last checked in with the fast-kernel-compile benchmark crowd (in last week's LWN Kernel Page) they had managed to get a kernel compilation down to just over 10 seconds. The record has fallen, however: Anton Blanchard has announced that he was able, through use of a 32-way PowerPC64 system, to build the benchmark kernel in 7.52 seconds. "...not a bad result for something running under a hypervisor."
Watch for sub-second kernel compilations, coming soon to a million-dollar machine near you...
"Discussions" of BitKeeper's licensing continue, not helped by the discovery of a temporary file race vulnerability in the BitKeeper installer. Readers of this page are more than familiar with the licensing arguments, though; we'll not repeat them this time.
Reworking the 2.4 VM patches. The word on the net for some time has been that the 2.4.x virtual memory subsystem almost works as it should; all that remains is to incorporate the last set of patches from Andrea Arcangeli. 2.4 maintainer Marcelo Tosatti has not yet integrated those patches, however; he has wanted to see them split up and documented so that he actually understands what he is putting in. This seems like a not unreasonable approach for a stable kernel maintainer to take. Thus far, however, Andrea has not found the time to rework his patches as requested, so they remain unapplied.
Andrew Morton has decided to try to break this logjam by reworking the patch and splitting it up into a form suitable for submission to Marcelo. Andrew has, in consultation with Linus, annotated the patches and made his own changes (including leaving a few patches out entirely). The result is an interesting view into what still needs to be fixed with the 2.4 virtual memory implementation; it's worth a detailed look.
Andrea's 10_vm-32 patch was split into 24 individual pieces. Andrew has dropped eight of those, leaving 16 patches for consideration:
Together, these patches represent a great deal of work by both Andrea and Andrew. With luck, they'll find their way into a better VM in the near future.
Exit sections and monolithic kernels. The kernel has had, for some time, the ability to mark functions and data with an "exit" flag. The traditional use for this marker is to flag functions which are used at module unload time. Modules need cleanup functions so that they can be gracefully removed from the kernel. When those modules are linked statically into the kernel, however, they will never be removed. In this case, functions and data marked with the "exit" flag are simply discarded, making the kernel image smaller.
It's a worthwhile optimization. Anybody who has tried building a kernel with a modern binutils distribution, however, will have experienced the annoying, useless "undefined reference to `local symbols in discarded section .text.exit'" message that accompanies a failed link. The problem is simple: the kernel has numerous pointers to exit functions and data. Usually a human can determine that, in cases where the exit section has been discarded, those pointers will never be used; they are thus harmless. The linker doesn't see things that way, though, and newer versions refuse to complete the link when dangling exit pointers exist.
The workaround has been to define a devexit_p macro which causes exit pointers to disappear in non-modular code. It's a bit of a hack, but it gets the job done. The devexit_p calls have been slowly working their way into the kernel code.
But now Linus has come up with a different approach. Rather than discard all that exit code, why not keep it in the kernel and use it to gracefully shut down the hardware at system shutdown time? The code is there, one might as well make use of it, even if the kernel gets a bit bigger. devexit_p's days in the kernel may be numbered.
Other patches and updates released this week include:
Alternate kernel trees:
Core kernel code:
Section Editor: Jonathan Corbet
March 21, 2002