Linux in the news
All in one big page
See also: last week's Kernel page.
The current development kernel release is 2.5.0. For the first time since January, there actually is an official development kernel. As development kernels go, it's a relatively boring start - it's the same as the (allegedly) stable 2.4.15 release. A 2.5.1-pre1 prepatch exists, but it's limited to a couple of small updates and, of course, the 2.4.15 filesystem corruption fix. A 2.5.1-pre3 prepatch was released shortly before press time, with a few more cleanups.
The current stable kernel release is 2.4.16. This release, the first by Marcelo Tosatti, contains little beyond the filesystem fix. This release does seem to deserve the name "stable," though there are still some persistent complaints about interactive response in the presence of heavy I/O. The culprit appears to be the disk I/O scheduler; a real fix for that problem could be long in coming. The 2.4.17-pre1 prepatch contains a number of items including a new USB maintainer and a devfs update.
Those of you in the very old world may be interested in 2.0.40-pre3, released by David Weinehall.
The new development series begins - on a bit of a sour note. Linus pushed out 2.4.15 just before the Thanksgiving holiday, and made a copy called 2.5.0. Unfortunately, a late filesystem tweak broke the systems unmounting code, meaning that users found corrupt filesystems the second time they booted the new systems. Not the best beginning.
How could such a mistake happen? Linus's explanation is that he doesn't like doing maintenance.
The fact that I've held on to 2.4.x for too long, mostly due to the VM problems, really doesn't help. That just makes me _less_ likely to be careful. Especially when the last known VM problem was fixed (ie the Oracle highmem deadlock), I had a very strong urge to just "get the d*mn thing out to Marcelo".
He predicts that 2.4 releases will be of higher quality now that Marcelo is handling them.
Amusingly, there were arguably more complaints about the name Linus chose for this release: 2.4.15-greased-turkey. Linus's reasoning:
It's a worthy follow-up to the 2.2.x "greased weasel" releases, but as yesterday was Thanksgiving here in the US, and a lot of turkeys offered their lives in celebration of the new 2.5.0 tree, the 2.4.x series got christened a "greased turkey" instead of a weasel.
The extended version number caused things (like loadable modules) to be installed in a surprising place, and a few people didn't like that. Others suggested that "2.4.15-dead-duck" was a more appropriate name. Then, a patch was submitted for those vegetarian users out there...
Meanwhile, people are interested in how to avoid this sort of embarrassment in the future. Marcelo, evidently, is going to put out special "release candidate" prepatches before a stable release; these will be available for people to pound on for a period of time. If a particular release candidate appears solid, it will be turned directly into the stable release; otherwise a new release candidate will be made. Linus has not said whether he will follow the same convention, but, then, development kernels are supposed to be broken sometimes.
The prepatches move on kernel.org. There is a move afoot to better standardize the locations of prepatches on the kernel.org mirror system. It seems that each kernel release directory (i.e. .../kernel/v2.4/) will have a testing subdirectory under it. The upper-level testing directory will go away. Linus and Marcelo are already using this scheme for the 2.5 and 2.4 prepatches, respectively. It looks like Alan Cox will do the same for version 2.2, and David Weinehall will follow suit with 2.0.
A new USB maintainer. Greg Kroah-Hartman has been the acting maintainer of the USB subsystem for a couple of months. Now previous maintainer Johannes Erdfelt has made it official: Greg is the real, official USB maintainer.
Meanwhile, discussion has started on a set of 2.5 development goals for the USB subsystem posted by Brad Hards.
System calls or /proc files? Ingo Molnar recently posted a patch adding a new set of system calls which will bind a process to a subset of the available CPUs on a system. Ingo has also posted chaff, a tool for changing processor affinities of running processes. Nobody seems to doubt that this is a useful thing to be able to do. Binding processes can improve cache behavior. If a process is handling data from a busy device, attaching that process and the device's interrupt handler to the same processor can also help improve performance.
While the idea has been accepted, there are some complaints about the implementation. In particular some people think that new system calls should not be added for this sort of feature. Instead, the kernel should just set up some files in /proc which provide access to affinity settings. Robert Love has, indeed, provided a patch which implements this approach to affinities. The advantages, it is said, are a reduction in the size of the system call table and an easy ability for command-line tools to work with affinities.
Of course, not everybody likes the /proc approach either. Some systems do not have /proc enabled at all; if affinities are controlled only through that interface, they will not be available on systems without /proc. And, to some, anything that dumps more stuff into /proc is bad news. /proc is already messy enough as it is.
No resolution has been reached in this particular case. There is a bigger issue to be resolved here, however: how, exactly, should new kernel features be made available to user space? Should every capability be made available via a system call? Or are filesystem-based approaches the proper solution? At some point, the kernel hackers are going to need to come to a policy decision on this issue.
Other patches and updates released this week include:
Section Editor: Jonathan Corbet
November 29, 2001