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.