Linux in the news
All in one big page
See also: last week's Kernel page.
The current development kernel release is 2.4.0-test10. Linus took over a week off before releasing 2.4.0-test11-pre1 which consists of, mostly, driver updates. It also contains a new inter-module communication mechanism by Keith Owens which attempts to clean up the way loadable modules pass data between each other. Even at this late date, a new API can go into the 2.4 kernel...
And, as if that weren't enough, Alan Cox has gotten back into the 2.4 business with 2.4.0-test11-pre1-ac1. This patch contains a number of fixes that haven't made their way to Linus yet.
The current stable kernel release is 2.2.17. The 2.2.18pre20 prepatch claims to be the "last call for 2.2.18," assuming that all goes well.
Do loadable modules need persistent storage? Loadable modules, of course, are pieces of kernel code which can be inserted (and removed) at run time; they generally are device drivers, filesystems, and other bits of peripheral code. When a module is removed from the system, all of its data goes with it; if that module is later reloaded, it's just like the first time. No traces of the previous invocation (should) remain in the kernel.
It turns out that quite a few people would like to see a way for modules to leave some information behind; this "persistent storage" would help the module to reconfigure itself properly on subsequent loads. The dominant example seems to be sound card drivers. Currently, unloading then reloading a sound card driver will cause the mixer settings to be lost. If the driver could save those settings in the kernel, they could then be preserved across reloads.
There are two answers to the mixer problem which do not require persistent storage. The first is a simple "don't do that!" If the sound driver remains in the kernel, the mixer will not be reset. Some people, however, are fierce in the defense of their right to pull the driver out of the kernel; if they are not actively using it, they don't want it around. The driver can also be unloaded automatically in some configurations, whether the user wants it or not (though that happens much less since 2.2 was released and kerneld went away).
The other answer is to run a user-space program which saves the mixer settings to a file, then restores them after the sound module is reloaded. A number of distributions work that way now, at least at boot and shutdown time. The objection with this approach is that there is a delay between when the new driver gets loaded and the settings are restored. During that delay the user may be treated to a "deeply unpleasant scream" (so put by Alan Cox) if the default mixer settings create a feedback loop, or to silence during a really good part of that new MP3.
There are other uses for persistent data beyond sound cards; another common example is USB devices that may come and go. It would be nice to be able to unplug, then replug a USB device and have it work the way it did before. So persistence is likely to be supported in the future. Keith Owens has come up with a scheme which uses the existing module parameter scheme and works almost entirely in user space. If a module marks some of its parameters as persistent, the [cw]rmmod[/] utility will save their values to disk when it removes the module from the kernel. They can then be restored on the next module load. Since parameters are passed to the module at load time, there is no delay before they take effect. The scheme seems simple and elegant, and requires only an upgrade to modutils to work.
Why only gcc? Tim Riker stirred things up this week with an inquiry as to why only gcc was able to compile the kernel. Wouldn't it be better if it were possible to use other compilers as well? In fact, there would be some advantages to being more portable. Some compilers produce much better code than gcc on some processors, and moving to a new compiler can flush out bugs that just happened to work with the original one.
The problem, of course, is that the Linux kernel code is loaded with gcc-specific extensions. These extensions are used for a number of reasons, from simple code readability and maintainability, to performance, to the need to specify exactly what's going on in certain situations. Some of those extensions will eventually be superseded by C99 equivalents, but others are unique to gcc. Making them all portable while not impacting the quality or performance of the kernel code would be a long, difficult, and seriously unpleasant task.
Which leads to the obvious question...why bother? Most kernel developers show a lack of enthusiasm for this task, which is not helped by the fact that most of the possible target compilers are not free software. Thrashing up the kernel code to make it satisfy a proprietary compiler is not a very inspiring job. The one exception is SGI's "Pro64" compiler, which is said to produce far better code on the IA-64 than gcc does. Pro64, however, is derived from gcc, and is thus both free and able to handle gcc's extensions.
Somebody may yet dig into the task of porting the kernel to another compiler, but one should not expect it to happen soon.
What's up with the IrDA code? Part of the "getting close to release time" ritual seems to be a last-minute query as to why some particular subsystem is out of date and working poorly. The ISDN subsystem has filled that role in the past, but this time around we have a new player. This rant was posted this week asking why the IrDA (infrared) subsystem was so far out of date. The version in the mainline kernel not only does not work, it can crash your system as well.
IrDA, however, is not unmaintained; the problem is just that the patches are not getting into the kernel. Once again, we are seeing a situation where the IrDA developers are not working with Linus in the way he wants. Linus likes to see small, clear patches that he can understand and decide upon. Developers who send large chunks of code at long intervals tend to get ignored. Linus's response to the IrDA query was very clear:
I'm not fed patches. I'm force-fed big changes every once in a while. I don't like it. I like it even less when the very first screen of a patch is basically a stupid change that implies that somebody calls ioctl's from interrupts.
If the usual script is followed, the IrDA people will figure out how to package patches in a way that Linus wants to deal with. With luck, 2.4 will have a working IrDA implementation, perhaps after a one-time exemption to get the current big patch in.
More on the LynuxWorks patent. Thanks to an anonymous reader, we now have the text of the patent held by LynuxWorks that would appear to cover loadable kernel modules. This patent is a difficult read, even by the standards of such things ("The operating system of claim 1 wherein said core component includes a plurality of export functions, wherein the export functions of said core component and said first processing component are identified by export symbols, wherein said set of import symbols identify a corresponding set of kernel function calls issuable in the execution of said first component, and wherein said component switch includes a data table supporting execution time call redirection of said kernel function calls to export functions determined by a correspondence between respective import and export symbols.").
But the basic claim is "A computer operating system that can be flexibly constructed by inclusion of any of a plurality of processing components." That, of course, would describe many of the operating systems created over the last twenty years. This patent is not so old, however - it was granted last June. One can only assume that the company will not attempt to enforce it.
Other patches and updates released this week include:
Section Editor: Jonathan Corbet
November 9, 2000