Zack's Kernel News



The Linux kernel mailing list comprises the core of Linux development activities. Traffic volumes are immense, often reaching 10,000 messages in a 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.

MMC Maintainership

Pierre Ossman has stepped down as the MultiMediaCard (MMC) maintainer. It has been more than a year since he has been able to give the MMC code the attention it deserves, so he decided to call it quits. He didn't have a specific replacement in mind.

Ian Molton, who has done some serious MMC work, said he wasn't familiar enough with the deep dark guts of the code to take over; however, he did volunteer to be CC'd on MMC patches. Matt Fleming said he'd also like to see those patches. Roberto A. Foglietta also offered to help out with keeping the MMC project moving. Philip Langdale also volunteered to be CC'ed on MMC changes. Meanwhile, Andrew Morton said he would act as temporary maintainer until someone else turned up.

Around that time, MMC patches from various contributors started coming out of the woodwork. Andrew found he'd had a few queued up in his various trees for some time. Paul Mundt and Ohad Ben-Cohen submitted some additional MMC patches for consideration, and Adrian Hunter pointed to a batch of 32 patches that had been sitting around unattended.

At this point, the discussion skewed off into various people trying to figure out the best way for Andrew to manage an MMC tree, integrate it with linux-next, etc.

Status of ext4 Defragmentation

Clemens Eisserer asked about the status of ext4's online defrag feature, and Diego Calleja said it went into the 2.6.31 release. Clemens was overjoyed to hear this, especially since his impression had been that online defrag was dead in the water. It's not that he felt ext4 had bad fragmentation issues, but sometimes a little defragmenting would just hit the spot - like when Firefox would get hasty with its sqlite database. Theodore T'so gave a sober assessment of the status of ext4 defrag. For starters, he said, it wasn't exactly complete, even if it wasn't fully dead. The user tool still needed a lot of work, including being made to use the available ioctls that would be introduced when some pending ext4 patches made it into the tree. The defragmenting code was also, he added, not smart enough about defragmenting free space. He hoped all these issues would be addressed in the near future, but, he said, part of the problem was just not having enough people working on it.

Generic Support for Xen's Transcendent Memory

The Xen folks have implemented "transcendent memory" (tmem), a softer, squishier kind of memory that is not directly associated with hardware but can be provided virtually by the system. The idea is that tmem can be made a bit more abundant to user programs, at the cost of potentially disappearing without warning. Currently Xen is the only thing that implements tmem, but in theory tmem could be a generic resource implemented by anything that wanted it.

Dan Magenheimer and a bunch of others have written some patches implementing an API for using tmem's various features, as well as creating the infrastructure for it in Xen. Overall, various kernel folks seem at least interested in these patches, although some security concerns have drowned out other issues that might have come up. But no one seems fundamentally opposed to the tmem concept.

New List Handling Software for kernel.org

Matti Aarnio has started writing his own mailing list software, similar to majordomo. Matti's tool relies on MySQL for all mailing list data (not for emails, of course, just for data relevant to the lists themselves). He also improves on some of majordomo's security features, for example, making it difficult for one user to maliciously unsubscribe another from a given mailing list.

He didn't exactly give a cogent explanation of why he feels a whole new list-handling software tool needs to exist; but, then again, who says a guy can't just go have fun coding up some list-handling software when he wants to? So far he's only done a few days work on the project. We'll see if it develops a following.

More Options for Kernel Binary Compression

Albin Tonnerre has submitted patches to support LZO-compressed kernels, in addition to the gzip-compressed kernels that are already supported. This new support for LZO-based kernel compression is valuable (in spite of the fact that gzip actually achieves better compression than LZO) because LZO actually decompresses faster than gzip.

If the difference in compression ratios were not so high, and if the difference in decompression speeds were really great, then there would seem to be plenty of reason to consider adding LZO compression to the kernel. However, judging from the conversation so far, Albin still needs to justify LZO over other forms of compression, and he will probably have to answer other technical questions as well.

HTC Dream Phone Support

Pavel Machek has posted some patches to support the camera on the HTC Dream phone. His patches also provide some support for the touchscreen on the same device, based on code from Arve Hjønnevåg.

Microsoft GPLs Hyper-V Drivers

Microsoft has released their Hyper-V drivers under the GPL, Greg Kroah-Hartman announced recently. He praised Microsoft's Hank Janssen, Haiyang Zhang, and Sam Ramji, and a bunch of non-Microsoft folks, for making the whole thing happen. The patches essentially help Linux run well as a guest on top of a Hyper-V virtualized system.

Some folks, such as Dave Jones, wanted to review the patches, but found they needed so much cleanup that it was difficult to make sense of them. Others agreed, and Greg explained that first the known, working patches were going into the tree as they were, so that if any of the cleanups broke their workingness, it would be easy to track down the problem later. Once the drivers and the cleanups were in place, he said, everyone would be able to review the cleaned-up code without pain.

Balbir Singh asked how the drivers would remain synced up with Microsoft's version. How would updates be incorporated into the kernel? Greg replied that the long-term plan was for the in-kernel version to be the primary version. He said Microsoft would abdicate developmental control and remove the drivers from their own website. Hank from Microsoft also chimed in, saying, "It is my plan to use the kernel as my primary development area, and I will continue to provide Greg with updates. First step is to clean up the code to make sure it fulfills all kernel coding standards and requirements. Then I will start contributing new functionality."

Obstacles Still Facing PramFS

Marco Stornelli has submitted PramFS for inclusion in the mainline kernel. This was previously attempted in 2004 by MontaVista, and the effort failed in part because of patent issues surrounding the code. PramFS supports non-volatile RAM that can keep state across reboots and power-cycles, essentially turning that RAM into a hard disk available to the user.

According to Marco and to Daniel Walker, MontaVista has abandoned pursuit of a patent on the PramFS code, thus clearing the way for inclusion in the kernel.

The discussion immediately turned to technical considerations. Was the filesystem robust enough? Was there sufficient justification for a new filesystem as opposed to just using an existing one like ext2? Would it support standard filesystem features like hard links? In the midst of this, it was clear that Pavel Machek violently opposed PramFS, saying there wasn't sufficient justification for using it instead of something like ext2 or ext3, or even just modifying the RAMdisk code to handle persistence across reboots.

Ultimately, Marco was unable to convince Pavel of the value of PramFS, although Pavel did express interest in the fact that one of Marco's tests showed PramFS is significantly faster than ext2. This probably won't be enough to turn the debate around, however. It does seem as though PramFS might have to implement hard links, journaling, and other features before it is considered for inclusion.