See also: last week's Kernel page.

Kernel development

On the stable side, he is up to 2.2.13pre14. This patch contains an impressive number of patches at this point, and was considered to be a release candidate. Now, however, the kernel hackers have to figure out how they are going to fix the SMP IDE hanging bug that they recently tracked down first.

On the development side, the patches are up to 2.3.18ac10.

Should device drivers be part of the kernel source tree? This longstanding debate flared up as the result of a seemingly innocent query this week. Most device driver developers try to get their code distributed as part of the mainline kernel, but there are those who think that drivers should be kept - and distributed - separately. Arguments for this point of view include:

• There is an unbelievable number of devices out there, and more every day. Putting all those drivers into the kernel tree leads to source bloat and a huge, unmaintainable mess.

• The lifecycle of modern hardware can be shorter than the kernel development cycle. Separately-maintained drivers can be updated at any time; drivers in the kernel have to wait for a stable release.

• Hardware should come with a driver diskette for Linux, just like the ever-present Windows diskette. Users should be able to simply insert a vendor-supplied diskette and not have to worry about things like kernel rebuilds.

• Every driver in the kernel increases the patch-processing load on Linus. Linus is not an infinite resource.

• If drivers come with the kernel, users will simply have them. Having to go out on the web and track down a driver, perhaps choose between multiple variants, then integrate it into a kernel is beyond what most users will want to do.

• Kernel updates are much easier if the updated drivers come with the new kernel.

• Drivers that live with the kernel will better track changes in the kernel. People notice right away when a kernel change breaks something. There is also the view that drivers that are part of the kernel are less likely to be broken by kernel changes in the first place - developers will tend to see where particular features are used and try to avoid causing problems. There is no such feedback when the driver source is somewhere else.

• Device drivers in the kernel provide an important set of examples for kernel developers. Moving this development activity elsewhere would make the "code exploration" activity harder. Code that is in the kernel tree will encounter more eyeballs in general, and is more likely to be improved by people other than the maintainer.

• Drivers provided on vendor-supplied diskettes are all to likely to support only one distribution or packaging format. Until better standards are in place, having drivers in the kernel is the best way to insure they work with all distributions.

What does the kernel need in the way of a project management system? Here is the second version of a specification for a project management system for the kernel, which would handle source code management, bug tracking, and so on. It is an ambitious proposal, and calls for a lot of infrastructure which seems unlikely to ever get built. The kernel hackers, it seems, would rather be off hacking.

The first version, for what it's worth, suggested the use of Aegis in this role. That touched off a small but intense flame war between Aegis supporters and those of BitKeeper, which is actually supposed to be the kernel source management system one of these days, real soon now. (It is evidently already being used by the Merced porting project). The details are not of much interest; until BitKeeper is released for general use there will be no resolution to this sort of battle.

Other patches and updates released this week include:

• Knfsd 1.5.1 was released by H.J. Lu. For the time being, it is still necessary to apply H.J.'s patches to get a properly functioning NFS server under 2.2.

  H.J. has also announced a new mailing list (hosted by VA Linux Systems) for discussion on NFS development issues. It appears that VA wants to throw some (more) serious effort in this direction, in the hopes that Linux really will have an enterprise-class NFS implementation sometime soon.

• Ingo Molnar put out smp-2.3.18-H3. This patch is a rework of the x86 SMP and interrupt processing code which needs all the shaking down it can get before heading off to Linus.

• David Mentré has issued an updated SMP FAQ/HOWTO, the first in some time.

• Netfilter 0.1.9 has been released by Paul Rusty Russell. Netfilter is the new firewalling/masquerading system.

Section Editor: Jon Corbet

For other kernel news, see: Kernelnotes Kernel traffic Kernel Newsflash

Next: Distributions