Zack's Kernel News

Maintainership Changes

Paul Mackerras has announced his intention to hand over maintainership of the PowerPC architecture to Benjamin Herrenschmidt. Paul estimates a gradual transition period over the course of about six months. But because Paul was planning to go on vacation just before the 2.6.27 merge window opened, Ben was going to take over the whole operation during those two weeks. Various folks immediately peppered Ben with questions: Where was his git tree, if any? How were the branches going to work? And so on. Ben responded by setting up a tree on kernel.org and accepting patches.

Philippe Elie stepped down as OProfile maintainer and was replaced by Robert Richter, who submitted a patch to the MAINTAINERS file to that effect. Andrew Morton asked for more details, as well as how this would affect the fate of userspace OProfile.

Richard Purdie explained, "Maynard is taking over the overall control of oprofile userspace, with Daniel advising on the JIT stuff and me taking on responsibility for the arm kernel+userspace bits and the userspace GUI bits. Robert has volunteered to take a role of looking after the kernel side of things alongside or replacing Philippe, depending on how he feels about this – I'm not 100 percent clear on Philippe's position on things. John will still be around to keep an eye on us all."

Robert confirmed that he would be responsible for only the kernel side of OProfile. Without Philippe's approval of this change, it still seems a little bit up in the air. Typically, an official maintainer of any portion of the kernel (or any open source project, for that matter) would have to do a really horrible job to have maintainership taken away forcibly.

Vegard Nossum has created a kmemcheck entry in the MAINTAINERS file, listing himself and Pekka Enberg as co-maintainers. Ingo Molnár approved the change.

Driver Additions

Michael Buesch submitted a driver to allow all Brooktree 8xx chips to export all 24 GPIO (General Purpose Input/Output) pins to the kernel's GPIO infrastructure. This allows each pin to be used for either input or output, as desired. Michael was unable to find a GPIO maintainer to send his patch to, but Andrew Morton pointed out that David Brownell was the right guy.

David Altobelli has written a patch to support the HP iLO/iLO2 management processor. This hardware allows administrators to control their servers without having to log in at the console. David's driver allows userspace programs to interface with the server and give commands. Andrew Morton had some pretty significant technical comments, pointing out several bugs. He also pointed out that this was essentially an x86 driver only. Whether his objections are serious enough to stall the project or prevent it from being accepted into the kernel remains unclear. Typically, the kind of technical objections Andrew raises tend to indicate overall willingness to consider the patch.

Alastair Bridgewater has coded support in the driver for the eGalax touchscreen, as found in the HP tx1305us tablet PC and elsewhere. The problem was that this hardware handled events differently than the touchscreen driver supported. Alastair identified this particular hardware in the code and provided support for the different event format. However, complications arose when Alastair tried to submit his code. As Daniel Ritz pointed out, Alastair couldn't simply give the hardware an ID number that was already used; the code programmatically had to distinguish this set of hardware from others of a similar type. The two of them, along with Dmitry Torokhov, worked their way through that process, finally coming up with something that works – or that at least satisfies Daniel's objection.

Karsten Keil has written and submitted a new mISDN driver. Karsten said that the ultimate goal of this driver would be to replace the I4L driver architecture for passive ISDN cards. Ingo Molnár had some technical issues, but Tilman Schmidt said that as one of the maintainers of the old I4L drivers that would be replaced by Karsten's work, he was very pleased to see mISDN going forward. He couldn't get started on the replacement quick enough and asked for some interface documentation similar to that for I4L.

ZFS in the Kernel?

Sun has released some of its ZFS source code under the GPL, prompting the question: Why not include it in the kernel? The code is a 128-bit filesystem that layers all stored data across multiple block devices, checksums all data for better error detection, and keeps a snapshot history of all changes to a directory tree. Previously, ZFS was released under the Common Development and Distribution License (CDDL), which is incompatible with the GPL.

The new release got some kernel developers fairly excited, until they realized that Sun's GPLed version was read-only and lacked a lot of the code in the CDDL version.

Also, as Alan Cox points out, Sun and NetApp are in a legal dispute over the patents involved in ZFS. Trying to put those patented bits in the kernel would require permission from both combatants, which didn't seem likely.

Alan also speculated, "I can only read the Sun motivation one way – they want to look open but know that ZFS is about the only thing that might save Solaris as a product in the data center so are not truly prepared to let Linus use it."

Ricardo Correia has also been working on rewriting ZFS as a FUSE filesystem, and Patrick Draper reports complete success with it so far (although he recommends keeping solid backups, as with any filesystem). Meanwhile, Christoph Hellwig points out that read-only is better than nothing, and if Sun has released a read-only ZFS, it would be great to port that to Linux and incorporate it into the main tree.

Kevin Winchester, though admittedly inexperienced with this sort of thing, volunteered to try to do the port if no one else stepped up. No one did, so he decided to take it on.

Because Christoph was the catalyst for that, it's likely that he will offer various suggestions and other help along the way.

As David Kleikamp said, "When I ported JFS to Linux, I was completely new to Linux and open source, so tried to defer to the experienced developers whenever possible.

Christoph was a terrific help, offering a lot of suggestions and patches. JFS is a much better filesystem because of his help."