Sections:
Main page
Linux in the news
Security
Kernel
Distributions
Ports
Development
Commerce
Announcements
Back page
All in one big page

Kernel development

The current development kernel release is 2.1.125. In the announcement for this release, Linus stated his intention to move toward the 2.2 release shortly. By most reports 2.1.125 is relatively stable; folks in the Sparc and Alpha camps are happy that it works (almost) out of the box for them. For those who want to try out bleeding-edge stuff, Alan Cox release 2.1.125ac1which added a lot of fixes and enhancements; 2.1.125ac2 then followed with some more fixes and, importantly, the set of kernel NFS server fixes put together by H. J. Lu and others.

The list of 2.2 showstopper problems was posted by Alan Cox shortly after the 2.1.125 announcement. This version is now somewhat obsolete; a number of the problems have been fixed, and some others have been added. (The version on Alan's web server may be more up to date).

On the stable side, 2.0.36 prepatch 14 is out. This patch incorporates the new Adaptec SCSI driver and a number of other fixes. See the announcement for details.

When do you think the first 2.2 kernel will be released? The folks at Tummy.com have a pool going. Head on over and give them your best guess. They haven't said what the winner gets - maybe a free copy of 2.2.0?

A new version of the international crypto patch for 2.1 has been released by Alexander Kjeldaas. The purpose of this patch is to gather together all of the various cryptographic patches that exist for Linux into one convenient place. Due to silly laws in a few countries, this stuff will probably never be part of the official kernel, but is certainly useful anyway. See the announcement for information on what's included and how to get it.

Jon "maddog" Hall chimed in on the tail end of the UDI discussion this week. His comments are calm, reasonable, and favorable toward the concept.

A new kernel NFS patch has been released by H. J. Lu. Kernel NFS service, at least in the basic NFS version 2 UDP mode, is beginning to solidify, though some users still report some difficulties. Here's H. J.' announcement.

A new version of sysklogd is out, it includes a bunch of fixes. Here's the announcement.

Richard Gooch continues to work on devfs, he is up to version 70. There still has been no word from Linus on whether devfs will go into the kernel or not.

How can the kernel patch submission mechanism be improved so that Linus doesn't burn out? We've covered this topic over the last couple of weeks as things rose to a bit of a crisis point. Life has returned to mostly normal among the kernel developers, and discussion on this issue has died down, but people haven't stopped thinking about solutions.

One of those people is Larry McVoy. Larry's project is called "BitKeeper;" it can be thought of, in the simplest sense, as a replacement for CVS or any of the other source code management systems out there. BitKeeper has a number of distinct features, some of which are intended to make life easier for Linus as he tries to manage changes to the kernel.

A key feature will be the ability for people to add comments or changes to a patch which has been publicly posted. With this capability, a typical patch could follow this series of events:

Some (until now) unknown person posts a patch to fix a problem that he found.
Another kernel hacker, one with a bit of a reputation, checks it out, and decides that it's OK after a small tweak.
A prominent kernel hacker, seeing the approval from the previous person (who he respects), looks the patch over, makes a few more changes, and puts his approval on it.
Linus, seeing this approval, has a look at the patch and decides whether it goes in or not.

The point here being that Linus, and the developers closest to him, can be protected from the full, unfiltered stream of patches flying around on the list. By the time a patch gets to him, it has already been through a review process, and it contains the history of revisions and comments that were made on it on its way up. No more untested patches, no more patches with no hint as to what they do.

Larry is well positioned to do this work, having written the source management system used at Sun. He tells LWN that the BitKeeper idea has been discussed with Linus and some other kernel hackers, and they have expressed a willingness to try it out. The project is moving forward, though, as Larry puts it, he occasionally "runs out of steam when he encounters the license police." (Larry would like to earn some money from BitKeeper, while keeping it free for free software projects, so that he can continue to pay his mortgage). With luck, BitKeeper will help to keep the kernel development process working smoothly for some time.

For more information on this system, see the bitkeeper web page.

Is the kernel source obscene? In the (seemingly) masochistic spirit that inspires people to monitor offensive material in prime-time TV shows, Tigran Aivazian went grepping for strong language in the kernel, and was surprised to find what he was looking for. At that point, what can you do besides post the results to the kernel list? There doesn't seem to be any sort of strong feeling toward sanitizing the source, thankfully.

OK, OK, we know a bunch of you want to see it. For those who are not easily offended here are Tigran's results.

October 15, 1998

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