See also: last week's Kernel page.

Kernel development

Interface stability in the Linux kernel has been the topic of discussion for a couple of weeks now. It all started with this note from a staff member at MIT complaining about how another incompatible interface change had happened, and describing, in detail, the sorts of difficulties such changes can cause when many thousands of machines are in use. It seems to be generally agreed that, while incompatible changes occasionally need to be made, they should be kept to a minimum, especially within a single stable release series.

The discussion shifted to the kernel module interface, where there is less consensus on how things should be done. Kernel modules, by their nature, have much more direct access to the internal workings of the kernel, and are thus much more easily affected by changes. Usually, but not always, all that is required is a recompile to make a module work again after a change has happened.

Unfortunately, "recompile the module" is not a recipe that sits well with users of binary-only modules. Recent victims here have included users of the AFS file system - often large universities with a lot of systems. Linus's responses to the complaints varied from quite unsympathetic to completely dismissive. Further on he explained his reasoning in a bit more detail. The executive summary could be that while he allows binary-only modules to be inserted into the kernel, he does not much like them and would not be terribly upset if they simply went away.

There are good reasons behind this position, but it will certainly cause problems for Linux users who can only get support for something they need via a binary module. This, in turn, can only lend support to the critics who claim that Linux is immature, not "enterprise ready," and that it suffers from far too many versions. This is exactly the sort of issue that could force users to one of the other free unix systems, or perhaps cause an eventual fork in kernel development.

UltraPenguin 1.2 will not allow 64-bit user code to run, due to a couple of hardware bugs in some UltraSparc processors. The exact nature of the bugs is unclear, but it seems that they allow any user to halt the processor, not a desirable thing. The real problem is that, according to David Miller, Sun will not release information about the bugs without a nondisclosure agreement in place. Since an open workaround in the UltraPenguin kernel would disclose the bug, no fixes can be had via that path. Thus the problem remains unfixed - and 64-bit user code remains unrunnable - until somebody can figure out the problem via some other means.

Here is your chance to own the entire kernel release history on CD. Riley Williams, who put together the Kernel version history archive is now packaging the whole set up and is considering making the CD's available for a small fee. See his announcement for details.

FTape 4.x has been ported forward to the 2.2 kernel, though it is still considered to be unstable at this time. Details and a download address can be found in the announcement.

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