See also: last week's Kernel page.

Kernel development

Bug-fixing work has been going on in an especially high gear over the last week. One senses that the kernel developers really want to get the 2.2 release out the door and done with - it has been a long haul. An especially active area has been memory management. Linus took a hatchet to the memory code with 2.2.0pre5, incorporating much of Andrea Arcangeli's work, but in his own way. Since then many cycles of patches and benchmarks have been passed around, with additional tweaking being done. As of pre7, Linus seems to be reasonably well satisfied with the results, and has put further memory management work on the back burner.

H. J. Lu's long-awaited kernel NFS fixes went into 2.2.0pre4, something which escaped our notice last week. Further NFS work has been going on, to the point that NFS over TCP works on the client side (2.2.0 will almost certainly lack the ability to do NFS over TCP as a server).

Alan Cox has put together a "hint sheet" for folks trying out the 2.2pre kernels as their first experience with the 2.1 series. Have a look on his web site. It could save you some frustration.

One additional hint that people seem to need: the 2.2 kernels are simply bigger than the 2.0 series. They are big enough that the old "zImage" format for the kernel image will no longer work; one must now use the "big zImage" ("bzImage") format for all but the smallest of configurations. Build the kernel with "make bzImage" and otherwise proceed normally. As long as you have a reasonably recent boot loader, all will work fine. The next person who ignores this and asks about the "System is too big" message on the list may not like the responses that come back...

Is your distribution 2.2-ready? The new kernel needs a different environment, including current versions of a number of utilities (especially networking), some changes in boot scripts, etc. The results of some discussion are:

• SuSE 6.0 is supposed to be completely ready for 2.2.
• Slackware 3.6 claims 2.2 readiness.
• The Debian "slink" release, hopefully to hit the net Real Soon Now, is "almost" 2.2 ready, with a couple of small problems.
• Red Hat 5.2 is a little behind, with some old utilities. Nonetheless, your editor is running the 2.2pre kernels on a vanilla 5.2 system without ill effect (though HJ Lu's knfsd startup scripts were needed).
• "Rock Linux" is currently based on the 2.2pre kernels. No, we hadn't heard of it either; learn more at this site.
• No word was heard from users of Caldera, Pacific Hitech, etc.

As a sign of how much interest there is in the 2.2 kernel series, the size of the linux-kernel mailing list has tripled since the 2.2.0pre series began. The result has been a large increase in traffic on the list, with the result that smoke was seen pouring out of vger.rutgers.edu, the machine which handles the whole thing. Turnaround time on the list grew to over 24 hours at one point; David Miller had to disable anonymous CVS access for a while to allow the backlog to be reduced somewhat. Things since then have stabilized.

Printing on SBUS-based UltraSparcs came up again; the official word is that the parallel port driver for SBUS machines is not supported; in fact, it doesn't even compile. Christopher Platt is working on the problem; he posted a patch which gets the driver to the point of compiling and doing some simple things. He's interested in feedback; give it a try and let him know how it goes.

A new RAID release has been announced; this release contains bug fixes only. The patch applies against either 2.0.36 or 2.2.0-pre5, so just about anybody should be able to make use of it.

When your editor was younger and had time for computer games, he was a fairly avid netrek fan. The netrek folks used to circulate a "frequently offered clever suggestions" list, the idea being to head off recurring discussions on ideas that had been rejected long since. Perhaps the Linux kernel list could use such a document, if the current discussion on whether the Linux kernel should be rewritten in C++ is any guide.

Of course, an experiment with C++ was tried back in the dim and distant past, with such poor results that the kernel was reverted back to C almost immediately. The extent to which this was due to the poor quality of the g++ implementation at that time is debatable (and debated), but there is a certain amount of truth to the claim that C++ encourages too much weirdness going on in the background. It is hard for a kernel developer to look at a piece of code and really know what is going on. Thus there is almost no sentiment in favor of C++ among serious kernel developers.

The debate does provide the opportunity for some interesting quotes, though...

"Been there, done that, didnt like it threw it out"

--Alan Cox

"One day, computer power will eventually outstrip demand, and OS engineers will be free to use friendly languages like LISP again.. until then, I think we're stuck with C."

-- Oliver Xymoron

"The day the Linux kernel starts to go c++ is when I stop working on it. With C I can see the cycles I get as I code, with c++ there is no chance."

-- David Miller

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."

-- Ted Ts'o

"So instead of C++ we should be talking about converting to Bliss?"

-- Mark Wood

"Do we really want to replace straight-forward use of macros with anything that requires 150 pages to be defined clearly?"

-- Martin Mares

Just in case you don't get enough kernel news here, a new kernel development newsletter has been started, called Kernel Traffic. Its official launch is supposed to be Friday the 15th, but there is a page at that address now.

Since we're a weekly publication, chances are we'll be behind a rev or two on the kernel release by the time you read this page. Up-to-the-second information can always be found at LinuxHQ.

Next: Distributions