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-pre2. This patch includes integration of the new netfilter code, many architecture-specific tweaks, USB updates, and a number of other small changes.
There is a 2.3.99-pre3 prepatch (a pre-prepatch?) available, in its seventh version as of this writing. The patches are actually beginning to look like something from frozen code: this one is made up mostly of a lot of little fixes. There is also a new "hotplug" master configuration option (which controls PCMCIA and other such technologies), 3Dfx Banshee/Voodoo3 frame buffer support, nVidia Riva framebuffer support, a master configuration option for WAN devices, a USB Mustek MDC800 digital camera driver, Sun 3x support, an IEEE-1394 update, a PCMCIA Xircom Tulip ethernet driver, IDE layer tweaks, and a partial merge of NFSv3 client support.
As part of the process of getting 2.4 out, Alan Cox has posted the latest 2.4 jobs list.
The current stable kernel release is still 2.2.14. The latest 2.2.15 prepatch (2.2.15pre15) was released with a comment of "Ok this should be it. I hope." We'll see.
Will 2.4.0 be a "brown paper bag" release? Here's a Technocrat posting that raises that fear. "However, major packages won't compile on it. UDF has serious bugs, causing kernel hangs. In the 2.3.99 stage, the entire filesystem directory tree and initialisation code is being heavily re-written. The kernel configuration code is being re-organised. That is NOT where a program needs to be, when it's just about to be released as a stable package."
It is true that a number of major changes have gone into the kernel in recent times. But nobody (except this LinuxGram story) thinks that the current code will be released as 2.4.0. The quality of what goes out depends very much on the current shakedown period. The more people who test out the 2.3.99-pre kernels and report on their experiences, the better the end result will be.
The addition of master configuration options for broad subsections of the kernel code is still going on, and creating a bit of confusion. 2.3.99-pre1 added the CONFIG_IDE configuration option; if this option is not set, the entire IDE subsystem is compiled out of the kernel. A number of people are evidently missing this option when upgrading, then wondering why their systems don't boot anymore. When upgrading to the 2.3.99-pre kernels, pay attention to the new options.
A new reiserfs patch is available, see the announcement for details. The reiserfs debate continues, with its proponents still hoping to get it into the 2.4 kernel. The reiserfs folks seem to be reaching some sort of understanding with the VFS people, which is a good sign. The latest issues have to do with how reiserfs interacts with NFS; evidently it should work OK for now, but planned changes in the future could change that situation.
Ethernet disconnect. Donald Becker's name is known to just about anybody who is familiar with the kernel code. He has singlehandedly written a large parcentage of the ethernet drivers in the system. Chances are that this web page came to you by way of one of his drivers. Donald's work also did a lot to get the early Beowulf clusters off the ground. It is safe to say that he is one of the founding fathers of Linux.
It is thus unfortunate to see Mr. Becker increasingly isolated from - and in conflict with - the kernel development community. The loss of an important kernel developer seems likely. This state of affairs is the result of a conflict in working styles between Donald and most of the rest of the kernel developers. It's an example of how managing open source development is not always as easy as it might seem.
Donald likes to maintain his drivers separately from the kernel. They have their own web page, mailing lists, and release cycles. Donald's drivers are explicitly portable across kernel versions, so that even very old kernels can run modern versions of the driver if need be. His preferred mode of operation would be to simply drop new versions of the drivers into the kernel occasionally as releases dictate. He is unhappy that the driver API has changed a lot (as it has), making cross-version portability difficult. He also seems disgruntled that one of his API changes got rejected in favor of a different implementation.
Linus, instead does not like this mode of operation at all. He always prefers to see small, incremental changes to code that he can understand (and modify or reject if he thinks it's right); getting a whole new driver in one chunk does not suit him. He claims that keeping the driver development separate deprives it of a whole community of testers; putting driver changes into the kernel more often will get them exercised by everybody who installs new kernels, and not just those on the driver development lists. Linus doesn't like to see drivers filled with backward-compatiblity code, and does want to see them updated quickly to new interfaces. Finally, Linus has no qualms about changing interfaces and requiring such updates - the alternative, according to him (and many others) is a kernel that slowly fills with cruft and old, broken interfaces and becomes unmaintainable.
The reason that this issue is coming to a head (again) now is that others, such as Jeff Garzik of MandrakeSoft, have essentially taken over as the maintainers of some of Donald's drivers. To some it may look like a sort of power grab. But the developers involved feel that something had to be done, since the drivers in the kernel simply were not working.
The situation almost looks like a code fork. Donald has his versions off in one corner, while the kernel code is proceeding in a different direction under new maintainers. Depending on your point of view, it could look like an unfortunate rift caused by personality and work-style differences, or like an open source project reacting to fix something that wasn't working. Either way, it is hard on some of the people involved.
The shared memory changes are still causing problems, as reported last week. The main difficulty is an interface change; before it was possible to attach to a shared memory segment that had been removed (as long as you had its ID), the new implementation does not allow this. Anybody who has actually had to work with the unpleasant SYSV shared memory interface knows how easy it is to clutter up the system with dead shm segments that persist forever; the ability to delete them up front is a nice feature.
The latest victim of this change would appear to be XFree86 4.0, which takes advantage of this feature to avoid leaving segments around in the case of an unplanned exit. The number of complaints has been such that it appears, as of this writing, that the old behavior will be restored in 2.3.99-pre3.
The mount-time ext2 block/inode checks are going away if this patch by Ted Ts'o goes in. The check is a simple integrity check performed at mount time; it's why Linux seems to take so long to mount a disk. It has been possible to override the check for years with the check=none option, but that is not the default. The thinking now is that the check serves no useful purpose - fsck does a much more thorough job. So, in the interest of faster boots and smaller kernel code, the checks look like they are on their way out.
Overcommitting of memory by the Linux kernel continues to consume massive amounts of linux-kernel bandwidth, though very few of the participants at this point are actually developers. Memory overcommitting was covered in the March 9 LWN and not much has changed since then. One exception is the creation of the strict memory project, which hopes to inspire the creation of a patch which disables memory overcommitting.
Other patches and updates released this week include:
Section Editor: Jonathan Corbet
March 23, 2000