See also: last week's Kernel page.

Kernel development

The current stable kernel release is still 2.2.16. The latest 2.2.17 prepatch is 2.2.17pre19. This prepatch was put out on August 18 as the final one, but the official stable release has yet to happen as of this writing.

vger.rutgers.edu is no more. As was reported last week, the system which has handled linux-kernel and many other mailing lists for years suffered a disk disaster and went off the net. David Miller had been planning to move the lists anyway (the folks at Rutgers were getting tired of them), so this failure was the obvious opportunity to finish the job.

The lists made a brief stop at vger.redhat.com, but not everybody was happy with the use of a vendor-specific domain. So the lists moved again - at least virtually - to their permanent home at vger.kernel.org. Some effort went into scrubbing every mention of Red Hat from the list headers. So, to all appearances, linux-kernel is redhat-clean, but Red Hat is still hosting the list - and doing the community a favor in the process.

If you were on any of the old vger lists, you should have gotten the note saying that you have to resubscribe to the new version. All of the lists are controlled by majordomo, so the usual subscription drill applies.

Driver locations, code sharing and the 'curse of the gifted'. This week's linux-kernel fight started out as part of an ongoing effort to reorganize the device driver tree. This reorganization has created some new directories such as "media" for things like video drivers and "input" for joysticks and such. Many drivers have found new homes in this process, but Linus drew the line at a patch that moved many of the USB drivers into the "input" directory.

Most Linux users, most likely, are not concerned with the details of the organization of the Linux kernel source tree. But the conversation took a more interesting turn when one person defended the change by saying that it would help to promote sharing of code between drivers. Linus answered back with a statement that code sharing is not all it has been cracked up to be, and that often it's better to just make a copy of something useful and modify it as needed.

Unsurprisingly, quite a few people disagree with this assessment. But it's worth considering his point of view for a moment. Linus is essentially saying that overzealous attempts to share code lead to modules that have been stretched beyond what they can comfortably handle. The result is a great many special cases, situations that maintainers can not test, and bugs. Rather than deal with all that, why not just make a copy that is able to properly handle a specific situation?

For what it's worth, Linus's comments are very general, but his examples all have to do with device drivers that try to support too wide a variety of hardware. There certainly are situations in that area where splitting code apart makes sense, especially when support of old, "legacy" hardware can be left behind in a relatively static driver. But the comments on code sharing in general have caused some concern among members of the linux-kernel list.

In particular, Eric Raymond joined in with an interesting letter accusing Linus of suffering from the "curse of the gifted." In Eric's view, Linus resembles the talented high school student who need not study to do well, and, as a result, never learns how. Linus's programming talents are such that he has never had to adopt the tools and techniques that most programmers rely on: things like source code management systems, bug tracking and regression testing systems, and, yes, code sharing.

The talented high school student in Eric's example falls apart at the University because the necessary study skills have never been developed. Eric fears that something similar could happen when the complexity of the Linux kernel reaches a point that it outstrips even Linus's talents. Will he, at that point, be able to fall back on the software engineering techniques that so many others depend on? If you accept Eric's "curse of the gifted" argument, it is an issue worth pondering.

Other patches and updates released this week include:

• Thomas Graichen has announced a new version of the Linux Kernel Source Reference, a web site that facilitates digging through any version of the kernel source and getting diffs between arbitrary versions.

• Jon Westgate has released a patch for the emu10k1 (SB Live) driver which enables input from the front panel S/PDIF port. It also allows direct recording from both the external S/PDIF and internal CD digital inputs.

• Yuri Pudgorodsky announced the availability of the "Virtual Environment System" (VE) for Linux. VE allows an administrator to set up multiple, independent application environments on a single system, with the idea of increasing system security.

• IBM has announced the release of a new debugging facility called "Dynamic Probes." It allows the placement of breakpoints anywhere in user and system space, making it well suited to kernel debugging. The package's web site seems to indicate that the patch only works for the 2.2 kernel, however.

• A patch to allow kernel profiling on PowerPC systems was released by Graham Stoney.

• Keith Owens has released version 2.3.15 of the modutils package.

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