Linux in the news
All in one big page
See also: last week's Kernel page.
The current development kernel release remains 2.1.131, as predicted. In Linus's absence, Alan Cox furiously released a set of "ac" patches, currently at 2.1.131ac12. Linus has now returned, and has put out 2.1.132 prepatch 1. This patch contains some NFS fixes, and some (but not all) of the patches from the "ac" series. A true 2.1.132 can probably be expected within a few days.
The 2.0.37 stable kernel pre-patch is up to release 3; see the announcement for information on what it contains.
International kernel patch 184.108.40.206 is out. This patch contains lots of good cryptographic code which can not be part of the standard kernel due to obnoxious national export laws. See the announcement for more.
The kernel compilation project has released a status update. This project seeks to put together an automatic compilation test suite which will quickly flag obscure compilation errors in new kernels. According to the update, about 75% of the compilations are now successful, which is a step in the right direction.
H. Peter Anvin has issued a call for kernel.org mirrors; he wants to have a well-defined mirror structure in place quickly, so that it can take the load of the 2.2 kernel release. See his note and join the mailing list if you think you can help.
The Distributed Inter-Process Communication project sent out an announcement this week describing the capabilities they have implemented. DIPC is essentially a kernel patch that extends the System V IPC capabilities (semaphores, message queues, and shared memory) to work across a network. Yes, you can have transparent shared memory across multiple machines. This looks like a useful system for a lot of applications; see the announcement for more.
An old question resurfaced this week: should Linux support direct I/O from user space?. Stephen Tweedie got things going by posting this patch which implements raw access to block devices. The real intent of the patch was to create an initial implementation of the O_DIRECT semantics; raw access to devices was just the easiest way to test it out.
Some of the other developers came out in favor of this approach. Alan Cox is interested in large video capture applications. Larry McVoy, instead, posted about an interesting "network disk" application that could use direct access. There were also the usual references to large databases wanting raw device access, though this appears to be an area of secondary importance.
Linus didn't like it. His position is that raw I/O almost never produces enough of a performance gain to be worthwhile, and that the complexities involved in locking down user pages for I/O operations are nasty and best avoided. He claims that most high bandwidth user I/O needs can be met with a combination of mmap (to map files into memory), mlock (allowing the (root) user to lock pages into physical memory), and the new sendfile system call. His real point here is that device drivers and the I/O system should not be messing with memory mappings.
Things are generally done as Linus says, so that's the likely outcome of the whole thing. Of course, any work in this area is a 2.3 issue; it's far too big to go into 2.2 at this point.
December 17, 1998