Kernel development [LWN.net]

Brief items

Kernel release status

The current development kernel remains 2.6.0-test9; Linus has not done a kernel release since October 25.

Patches do continue to accumulate slowly in Linus's BitKeeper repository. In keeping with the current policy, these patches are restricted to relatively important fixes.

Dave Jones has released a new version of his "Post-Halloween Document", which describes new features and things to watch out for in the 2.6 kernel.

The current stable kernel is 2.4.22. Marcelo released 2.4.23-pre9 on October 30; this patch backs out a couple of previous ACPI changes which had caused problems and includes some filesystem and driver updates. At this point, Marcelo is only accepting bug fixes for 2.4.23, so, with luck, we may see the first release candidate soon.

Comments (none posted)

Kernel development news

Loading NDIS drivers into the kernel

Hardware manufacturers which refuse to release programming information are a constant source of frustration for Linux users. Without that information, writing a Linux driver is nearly impossible. As a result, Linux users are unable to use the hardware in question, and the vendor loses potential sales.

A company called Linuxant has been offering a product called DriverLoader which is intended to relieve some of this frustration, at least for network devices. It is a kernel module that serves as a wrapper for Windows NDIS drivers. Using DriverLoader, a network device with a Windows driver can be made to function under Linux. There are, needless to say, a few objections that one could make to this product, one of which being that DriverLoader, itself, is not free software.

If the non-free nature of DriverLoader is your only objection, however, there is an alternative called ndiswrapper, which is licensed under the GPL. ndiswrapper is clearly in a very early stage of development, but, as its author (Pontus Fuchs) notes, "it works for me." With a bit of work, it could probably be made to work for a lot of other users as well.

The ndiswrapper module, when loaded, starts by registering a special purpose "misc" device; its only real reason for existing is to export an ioctl() call which can be invoked to load an NDIS driver. This call accepts the driver code from user space, performs the necessary relocation, and sets it up as Linux network device. In the modern world, using the register_firmware() interface might have been preferable to creating another ioctl() call, but that can always be done in the next revision.

Once the driver is loaded, ndiswrapper provides two separate glue layers to make the NDIS driver actually work. The first provides a set of net_device operations which can be invoked by the networking subsystem; these translate the requested operations into the calls that the NDIS driver will be expecting. At the other end, the wrapper code must provide emulation functions for a few dozen Windows routines that the NDIS driver will call. These map the requested operation (allocate an interrupt, remap I/O memory, feed a received packet into the kernel, etc.) back to their Linux equivalents.

All told, it is not a huge amount of code. The NDIS API is well enough documented that the requisite glue code could be written without a great deal of guesswork.

The wrapper approach to device support is far from optimal. Performance and reliability cannot be improved through the addition of glue layers, and many users will be unenthusiastic about shoving proprietary code - Windows code, even - into their Linux kernels. There is also the risk that hardware vendors might conclude that the existence of wrapper code frees them from the need to worry about Linux driver support at all. Against these disadvantages one can point out that the wrapper will enable Linux to be used on systems that would otherwise be inaccessible to it. This sort of wrapper module could also, with little effort, be turned into an ideal platform for the reverse engineering of unsupported hardware. A module like ndiswrapper may be a hard sell for the mainline kernel, but some users will certainly be glad that it is available.

Comments (12 posted)

The future of the Linux filesystem

The upcoming release of Microsoft's "Longhorn" version of Windows is two years off by the best estimates, but some people are beginning to worry about whether Linux will be able to compete with the features that Longhorn is promising. Even when factoring in the (often significant) differences between what Microsoft promises ahead of time and what it actually delivers, some feel that Longhorn might be good enough to be worth thinking about.

The Longhorn feature that attracts the most attention is WinFS, a new filesystem. WinFS will push an SQL-based database management system into the filesystem layer, enabling users to use searches to find their files. With some attention to metadata, Longhorn users will be able to ask the system to find, say, all of their William Shatner MP3s or all images of Tux the penguin in a swimsuit. Applications will be able to set up their own schemas for their specific object types; if mail agents can agree on a email message schema, then users should be able to switch easily between them.

Making all of this work well could be an interesting challenge. Making applications work well on top of WinFS will be another one. Even so, some people get the sense that Microsoft might just come out with something that people will want to use. If Linux wants to be able to compete on the desktop, it may have to provide a WinFS-like interface too.

There are two projects out there which could provide something similar to WinFS's capabilities. Thankfully, neither one proposes to put an SQL query engine into the kernel.

One is ReiserFS, a topic which has been covered here before. Hans Reiser believes that the existence of any sort of storage layer above the filesystem implies that the filesystem itself has failed in its duty to organize information in the required way. His Naming System Venture paper describes a world where filesystems impose no structure on data, leaving that task instead to the user. A query language (not SQL) would enable files to be found via free-form searches. In the Reiser vision, everything - even complex databases - could be implemented directly in the filesystem.

The current state of ReiserFS is far from that vision. Work so far has concentrated on the infrastructure that will be necessary to implement the wider vision - and on the features that can attract funding for their development. The Reiser4 filesystem, which is in testing now, adds features like built-in transactions, even better small file performance, and a well-developed plugin architecture which makes it easier to add advanced features to the filesystem. The Reiser4 developers hope to get it into the 2.6 kernel, but it is not clear whether that will happen.

The other approach doesn't involve the kernel at all. The GNOME Storage project plans to "replace the traditional filesystem with a new document store," but, in fact, it is built on top of existing filesystems and operates entirely in user space. GNOME storage is accessed via (a modified version of) gnome-vfs, so it can operate in user space and be used by GNOME applications without modifying those applications. Underneath the hood, GNOME Storage uses PostgreSQL as its object store, though efforts are being made to make the system portable to other databases. GNOME Storage has an ambitious set of goals; see the features document to see where they are heading - and what has already been done.

Where either of these projects will end up is unclear at this time. What is clear, however, is that interesting work is being done in the area of Linux object storage. By the time Longhorn starts showing up on desktops, it might not be the only system with an interesting new approach to storing user data.

Comments (12 posted)

Patches and updates

Kernel trees