Zack's Kernel News

The Linux kernel mailing list comprises the core of Linux development activities. Traffic volumes are immense, often reaching ten thousand messages in a given week, and keeping up to date with the entire scope of development is a virtually impossible task for one person. One of the few brave souls to take on this task is Zack Brown. Our regular monthly column keeps you abreast of the latest discussions and decisions, selected and summarized by Zack. Zack has been publishing a weekly online digest, the Kernel Traffic newsletter for over five years now. Even reading Kernel Traffic alone can be a time consuming task. Linux Magazine now provides you with the quintessence of Linux Kernel activities, straight from the horse's mouth.

SquashFS and FUSE

Acceptance of filesystems into the 2.6 tree appears to be on a case-by-case. Phillip Lougher's SquashFS encrypted filesystem has been getting rave reviews from users, with performance numbers to back them up. Greg Kroah-Hartman has also been maintaining it as one of a handful of non-bug-fix patches to the official Gentoo kernel, and he has been urging Phillip to submit the filesystem for inclusion in Linus Torvalds' official tree. Phillip himself has been reluctant, in part because of a lingering sense of the 2.6 tree as a "stable" series, and in part because he's not sure whether to submit the code before or after some further enhancements he wants to add. But with SquashFS affecting only a single directory, and with 2.6 undergoing massive development, and with folks like Greg calling for inclusion, is fairly clear that SquashFS will be accepted whenever Phillip chooses to submit it. FUSE (Filesystem in USErspace) on the other hand, has been trying to get into 2.6 but has so far been rejected on technical grounds. Miklos Szeredi submitted it recently, but Linus Torvalds was strongly opposed to the patch, at least in its current form. Aside from any actual implementation details that might be objectionable, Linus feels that a userspace filesystem is just inherently messy, because it attempts to isolate functionality from the rest of the operating system that really should be tightly integrated with it. In this regard, he has the same objections to a userspace filesystem as he does to a microkernel-based operating system like the Hurd. He feels that such a system, or such an operating system, can never fully succeed.

Software Suspend

The effort to suspend a running system to disk has certainly seen many twists and turns, and the ride is not over yet. Version 1 of the software, developed primarily by Pavel Machek, is already in the kernel and works, to a greater or lesser extent. Version 2 of the software, developed primarily by Nigel Cunningham, is not really a version jump as much as it is a reimplementation along somewhat different lines. Everyone seems to agree that version 2 should replace version 1 eventually, but Nigel is finding many hoops of fire to jump through before he can win acceptance. Not the least is the fact that Pavel, Christoph Hellwig and others want patches that incrementally transform version 1 into version 2. This is a nightmare for Nigel, because the two implementations are so different. On top of this, various key folks have strong objections to aspects of Nigel's current implementation. APIs have changed, and other parts of the code that have been criticized in the past have apparently remained in Nigel's patches unchanged. The whole situation with software suspend is a mess really; but the discussions appear civil, and everyone seems committed to roughly the same outcome. Suspending a running system to disk is inherently a sticky, ugly problem, because there is no sure way to confirm that all hardware will be in the same state after a restore as it was before the suspend operation. For this reason, any attempt to suspend a running system will be fraught with guesses, estimates, and magic incantations. It's wonderful that Nigel, Pavel, and the Linux developers in general, see value in tackling such problems for which there may be no ultimate solution, only a hope for improvement from version to version.

ioctls

Meanwhile, Edward Falk of Google has attempted the extremely daunting task of documenting Linux ioctls. The fundamental problem in documenting I/O controls is that anyone who writes a driver can create their own ioctl call, with a completely unique set of inputs and behaviors. Even cataloging all of the I/O controls is a nightmarish prospect, considering that not all Linux drivers are included in the official kernel sources. There are ioctls spread far and wide, and to go after them all would be insane. Ed has decided to tackle this vast array of ioctl implementations in small specific groups. He started with IDE ioctls and moved along to CDROM ioctls, submitting documentation patches that were applied happily. Perhaps his work will inspire others to tackle other areas of the kernel using ioctls.

Maintainership

The issue of maintainership is one that is constantly undergoing refinements. One recent issue is whether to include moderated mailing lists in the MAINTAINERS file. This question might never have come up if the linux-kernel mailing list were moderated; but Linus Torvalds has always believed that everyone should be able to post their bug reports and questions to the list, so that the kernel developers would have access to the information they need to improve the code. On the other hand, the list admins have recently decided that anyone who routinely raises off-topic issues or fosters flame wars can be banned from posting. So the situation is not entirely simple. In the past, listing moderated mailing lists in the MAINTAINERS file has been frowned upon, with the justification that anyone should be able to post their bug reports to the mailing lists of particular kernel sub-projects, just as they can with the primary linux-kernel mailing list. And recently, Domen Puncer attempted to submit a patch that would remove some moderated lists from that file. However, Alan Cox and others prevented this, on the grounds that even if a non-member could not post to a given list, they might still want to subscribe to it and post again then. In a less controversial move, Jeff Garzik recently began marking certain projects as deprecated in the configuration scripts. His idea is to make sure anyone at all interested in those projects has a chance to speak out against removing them before the time comes. Projects that are broken, unmaintained, or that perform the same function as another project, are currently targets for elimination. MCA (Micro Channel Architecture) maintainership has recently changed hands. Adrian Bunk recently submitted some cleanups to that code, and David Weinehall, the former maintainer, said he had passed the torch to James Bottomley, who should receive all MCA patches starting immediately. James in turn posted a patch to the MAINTAINERS file, listing himself as the official MCA maintainer. He acknowledged that he wasn't exactly rolling in MCA hardware, and no sooner had he said that, than Alan Cox sent him a huge pile of MCA-related hardware. Apparently James will now have plenty to do with MCA code. In a completely different context, Adrian tried to remove Michael H. Warfield as the maintainer of the orphaned Computone Intelliport Multiport card. Andrew Morton didn't like this idea, and Jim Nelson in particular felt that including the old maintainer in the MAINTAINERS file would at least allow potential new maintainers to figure out who to take the reins from. But Adrian argues strongly that the MAINTAINERS file is intended for developers to consult, in order to find out where to send their patches. Adrian's idea is that if necessary, an alternative file listing the current status of all projects could also be maintained. But this would take a lot of effort. It's unclear how this will ultimately be handled, but it is a certainty that more folks will be heard from before the issue is resolved.