See also: last week's Kernel page.

Kernel development

And that is a good thing. A certain amount of grumbling about the stability of 2.2.2 has been heard in recent times; some have compared it to a development release. A lot of the problems seem to be with NFS, which could be a source of complaints for a while yet. NFS was orphaned for too long in the 2.1 cycle, it has some catching up to do. The Alpha compilation problems didn't help either. Nonetheless, 2.2.2 has worked quite well for most people who have used it, and 2.2.3 should be even better. The 2.2 series is a quality release.

Alan Cox, of course, has jumped out ahead with 2.2.3ac1. It contains quite a few fixes, including more NFS stuff.

What byte ordering will the Merced port use? This discussion - perhaps a bit premature - has been based on the assumption that Merced, like a number of other modern processor chips, will be able to operate in both big-endian and little-endian modes. A certain vocal contingent thinks that big-endian ordering should be used. Arguments for this approach cite compatibility with the (big-endian) TCP/IP protocols, as well as some things about making hex dumps easier to read.

Linus's answer to big-endian proponents is quite simple: "Not a chance in hell". His reasons are (1) a claim that there is never any reason to prefer one byte ordering over another, and (2) the x86 emulation mode will require little-endian ordering. Different orderings for the x86 and IA-64 native modes is not open for discussion - nobody has been pushing for that. So the question is pretty well resolved.

As an interesting aside, Linus posted this note on why he thinks that old x86 binaries running in emulation mode will actually execute faster than native IA-64 binaries. It mostly has to do with the huge expected size of the Merced binaries. He leaves us with this chilling thought... "For example, have people realized just how large something like KDE+StarOffice is? Imagine blowing that up by a factor of three or so."

Lots of patches and packages were announced:

• DIPC 1.1b is available for the 2.2 kernels. DIPC (Distributed Inter-Process Communication) is a package aimed at clustering applications; it makes the SYSV IPC mechanisms work across the net, and also provides a slick transparent shared memory capability. The DIPC folks also issued an invitation for other developers to start hacking on the system.

• GNU Queue 1.20 is out. This package is also intended for clustering applications; it provides for load balancing and (almost) process migration across cluster nodes.

• Ted Ts'o announced a new version of the serial driver, currently packaged separately from the kernel. It can be used to bring a lot of new features back into the 2.0 kernel, but it also adds support for the new 16C950 UARTs, which, according to Ted, are very nice.

• PPSkit-0.6 provides high-resolution timekeeping to the kernel. This package is still very much in an experimental state.

• Richard Gooch's Model-Specific Registers patch is at version 12. Richard has also put out a call for testers who have AMD CPU's.

• LVM 0.6 (the Logical Volume Manager patch) is out. "...still considered alpha."

• Swsusp v5 is available. This patch creates a "suspend to disk" capability for all machines - whether or not the system has APM support.

• Version 0.0.2 of the 802.1Q VLAN system is out.

"Why debate changes on linux-kernel? After all, Linus makes all the decisions in the end anyway." After hearing this point of view one time too many, Larry McVoy responded with not just one but two separate, well-written messages on why development issues need to be debated. Relying on Linus is not only a cop-out, but it's guaranteed to bring on more "Linus burnout" episodes in the future. Rather than send everything up to Linus for judgement, the onus should be on developers to insure that almost everything that gets to Linus will be judged favorably.

Implicit in all this, of course, is the question of how things will work when Linus is not there any more. Linus may have no immediate plans to move on to other things, but he served some notice at his LinuxWorld keynote: "Basically, I'm a very selfish person and I really don't care about all of you. I care about doing what I enjoy." If Linus wakes up one day and decides he's no longer enjoying himself, he may well be gone.

And remember that he has been doing this for almost ten years. That day could come sooner than many people expect.

The point of all this, of course, is that the kernel development community needs to be able to function well in Linus's absence. The better we all do at getting the important decisions made before they ever reach him, the better prepared we will be for that day when he is no longer around. Linus's departure - hopefully a long way off - will not be the end of Linux. With a proper development discipline in place, it need not even be all that traumatic.

Another article describing the new features of the 2.2 kernel can be found on the openresources.com site.

Section Editor: Jonathan Corbet

For other kernel news, see: LinuxHQ Kernel traffic

Next: Distributions