See also: last week's Kernel page.

Kernel development

The current stable kernel release is still 2.2.17. The 2.2.18 prepatch series is up to 2.2.18pre9. With pre9, Alan Cox finally merged in the long-awaited NFS fixes; this is good news for those hoping for decent NFS server behavior from the 2.2 kernel.

One more 2.0.39 prepatch came out in the form of 2.0.39final. Unless something truly earthshaking comes up, this patch will go out as an official 2.0 stable release.

Another step toward 2.4.0? On September 17, the 2.4.0-test9-pre2 announcement came out with an interesting set of remarks:

I think we're getting to the point where there are no major known bugs. That means that as of the final 2.4.0-test9 I will no longer accept any patches that don't have a critical problem (as defined by Teds list) associated with them.

So when you send me a patch, either bug Ted to mark the issue as "critical" first, or pay me money. It's that easy.

Linus has not made any public remarks on the amount of money that would be required to get a patch in. However, at least a couple of developers seem to have concluded that a more economical approach is to offer Ted Ts'o a nice bottle of liquor.

2.4.0 still does not lack for known issues in need of fixing. But it is getting closer to that final stabilization phase before the official 2.4.0 release can go out. That release, of course, is certain to have a few remaining bugs - perfection is hard to reach. But at some point you have to call something an official stable release to expand the user (and thus testing) community.

Meanwhile, there has been a bit of grumbling in the ranks from a small number of developers who are getting tired of the feature freeze. One developer has even started up his own 2.5 tree and offered to make it available to others who are looking for a place to hack on new features. The problem, of course, is that stabilizing 2.4 requires the attention of as many developers as possible. It's important to truly have enough eyeballs to make the bugs shallow. If the hackers go off on some sort of unofficial 2.5 effort, the 2.4 kernel will suffer.

So patience is counselled for those wanting to work on 2.5. They are still going to have to wait for some time. In the past, Linus has always let a good chunk of time go by - on the order of a couple months - after the first stable kernel release. Only once it's truly stable will he open up a new development series and start the process over again.

What about BitKeeper? Last week's kernel page discussed a proposal for a new kernel patch management system that had been posted. It didn't take too long for the inevitable question to come up: what about BitKeeper? It was, after all, once said to be the kernel source management system of the future. One of Larry McVoy's reasons for creating BitKeeper in the first place was to try to make Linus's job easier.

These seem to be the reasons why BitKeeper is not being pushed at this time:

• BitKeeper is a large and complicated beast. By all accounts it repays the time invested to learn it, but kernel hackers tend not to have a lot of spare time. Not everybody agrees that BitKeeper is hard to learn, but getting people to put time into learning a new tool is always a challenge.

• BitKeeper is not open source software - though it is very close. See this 1999 LWN feature for a description of the issues surrounding the BitKeeper license. Some kernel developers have very strong feelings about free software, and some of those (notably Alan Cox) have said they would not use BitKeeper for that reason.

• Linus has not come out and said he would use the system (though he does plan to try it).

All of these issues feed the fear that an insufficient number of kernel hackers would use BitKeeper. And if only a few use it, it's not worth the trouble of learning how. So the plan for now is to try to put together a much simpler system and hope that it actually gets used. It is interesting to note, however, that Linus only plans to use this system until 2.4.0 comes out. What happens thereafter is anybody's guess.

Other patches and updates released this week include:

• A new RTL8139 net driver patch was posted by Jeff Garzik.

• David Howells has released a new version of his "WINE in the kernel" patch.

• Rik van Riel's VM code is now in the -test9 prepatch, but he's not done yet. Here is his TODO list for virtual memory management in the 2.4.0 time frame and after.

• Vojtech Pavlik has posted a new version of his VIA IDE driver.

• Dave Higgen has posted a new NFS patch for 2.2.18 which is intended to complete the merge of the new NFS code into the upcoming stable kernel release.

• Stephen Tweedie has announced a version of the ext3 journaling filesystem which journals only metadata. Previous versions have journaled file data as well, which slows things down significantly. This version is faster, but is also very explicitly not yet ready for people to depend on.

Section Editor: Jonathan Corbet

For other kernel news, see: Kernel traffic Kernel Newsflash Kernel Trap 2.5 Status

Other resources: L-K mailing list FAQ Linux-MM Linux Scalability Effort Kernel Newbies Linux Device Drivers

Next: Distributions