Linux in the news
All in one big page
See also: last week's Kernel page.
The current development kernel release is 2.3.99-pre1. The patch is quite large (4M), but that size is deceptive - much of the patch is devoted to moving files around to effect a reorganization of the block driver hierarchy. This patch also contains a new DocBook-based documentation scheme and a few new documents (all written by Alan Cox), a new, much-reworked PPP implementation, an IBM LANStreamer driver, a MultiGate COMX driver, and Andrea Arcangeli's "elevator" disk scheduling improvements.
The current stable kernel release is still 2.2.14. The 2.2.15 prepatch is up to 2.2.15pre14 - a large patch with a number of new fixes. It still looks like at least one more prepatch iteration will be required before the stable kernel release happens.
The pre-2.4 series is coming. Linus sent out this announcement with the 2.3.51 release announcing that he is getting ready to start the pre-2.4 series - which is why the current release is 2.3.99-pre1. At this point, presumably, a real feature freeze has taken effect, and only bug fixes will go into the kernel. Regarding what may still go in, Linus has said "There's some NFSv3 and other stuff pending, but those who have pending stuff should all know who they are, and for the rest it's just time to say nice try, see you in 2.5.x."
This announcement has, predictably, brought out a number of people who have "pending" patches that they would like to see included. The biggest discussion by far was about reiserfs, Hans Reiser's new filesystem that was discussed in the November 11, 1999 LWN. Quite a few people would like to see reiserfs go in, for two reasons: (1) they are actively, happily using it, and (2) if it goes in, the 2.4 kernel can claim to have a journaling filesystem. The kernel developers are trying not to be influenced by the second reason, but it is clear that many of them would like to be able to make that claim.
The inclusion of reiserfs has drawn some opposition, however, from those who do not like all of the changes that the patch makes. The leading opponent is probably Alexander Viro, who has been busy for a long time fixing up the VFS layer and fixing problems there; he sees reiserfs as being a new source of problems to fix.
The reiserfs folks are trying very hard to listen to the complaints and criticisms that have been going by, and seem to be bending over backward trying to address them. They really want to see their filesystem in the kernel. Linus has indicated that the inclusion of reiserfs is a possibility - for a later 2.4 release, if perhaps not for 2.4.0.
The great netfilter merge is happening, and should be essentially complete within another kernel release or two. Netfilter is the new implementation of the IP firewalling and masquerading subsystems. Firewalling and masquerading have been massively reworked, and now have a new set of utilities to work with them. ipchains is passť; things are now done with iptables and ipnatctl.
Netfilter actually contains a pair of compatibility modules that allow the old ipchains and ipfwadm utilities to work - so the transition should be relatively easy. But it is never too soon to think about heading over to the current way of doing things. Interested people may want to look at the iptables HOWTO and the ipnatctl HOWTO.
2.3.50 included the new shared memory filesystem. The shm filesystem cleans up the shared memory implementation, and helps in the provision of Posix shared memory segments. But its inclusion has broken a couple of things, and created some surprises for people.
First, SYSV shared memory is not available in the system until the shm filesystem has been mounted. It can be mounted directly with a command like:
mount -t shm shm /var/shmbut the proper fix is to put a line like:
none /var/shm shm defaults 0 0into the /etc/fstab file (the proper place to mount the shm filesystem is still a matter of debate). Note that the 2.3.51 implementation shows a file named / within the shm filesystem. This file - which would prove difficult to work with - is the result of a minor bug which has already been fixed.
The other surprise is that the new shared memory implementation breaks some applications. In particular, the Gimp as provided by some distributions dies an ugly death on startup. There are reports that recompiling the Gimp fixes the problem, though it is not entirely clear why. The real problem seems to be a change in shared memory semantics - one which makes Linux work more like other Unix systems.
The NT filesystem is unmaintained, and will likely be marked "obsolete" in the 2.4 kernel. It evidently still works, in at least some situations (not with W2K filesystems), but others report problems. It seems that not too many kernel developers see a great need for this filesystem. Unless somebody steps up and takes over its maintenance, the NT filesystem will eventually go away.
Preemptable kernel code? A continuing effort, led by Ingo Molnar, is underway to reduce the time it takes the kernel to respond to events. The low-latency work is inspired by the need to drive devices like sound cards and software modems without falling behind the data stream. The current Linux kernel, in some situations, is simply too slow to respond to do the job properly.
The approach being looked at currently is to change a longstanding assumption in the kernel: that kernel code does not get scheduled out unless it explicitly sleeps. This assumption only holds, of course, on uniprocessor systems, so its demise should not really cause too many problems. Except that there will always be problems that come out with this sort of change.
Linus has been pushing an approach that takes advantage of the existing SMP structure to make a preemptable kernel work. Essentially, it uses the spinlock primitives (which are currently no-ops on uniprocessor systems) to mark places where the kernel can not be preempted; any time that a spinlock is not held becomes fair game. Linus's approach explicitly changes nothing on SMP systems, on the theory that there is no need to preempt the kernel to get low latencies when there are multiple processors available. Not everybody agrees with that claim, however.
Thus far there has not been a patch proposed that Linus likes. In any case, a change of this scale may well have to wait until the 2.5 series. Making the kernel preemptable has enough potential to create strange bugs that it should have quite a bit of testing time to settle out before going into a stable kernel.
Other patches and updates released this week include:
Section Editor: Jonathan Corbet
March 16, 2000