TuxOnIce: in from the cold?

As flamewars go, the recent linux-kernel thread about TuxOnIce was pretty tame. Likely weary of heated discussions in the past, the participants mostly swore off the flames with a bid to work together on Linux hibernation (i.e. suspend to disk). But, there still seems to be an impediment to that collaboration. The long out-of-tree history for TuxOnIce, combined with lead developer Nigel Cunningham's inability or unwillingness to work with the community means that TuxOnIce could have a bumpy road into the kernel—if it ever gets there at all.

TuxOnIce, formerly known as suspend2 and swsusp2, is a longstanding out-of-tree solution for hibernation. It has an enthusiastic user community along with some features not available in swsusp, which is the current mainline hibernation code. Some of the advantages claimed by TuxOnIce are support for multiple swap devices or regular files as the suspend image destination, better performance via compressed images and other techniques, saving nearly all of the contents of memory including caches, etc. But its vocal users say that the biggest advantage is that TuxOnIce just works for many—some of whom cannot get the current mainline mechanisms to work.

Much of the recent mainline hibernation work, generally done by Rafael Wysocki and Pavel Machek, has focused on uswsusp, which moves the bulk of the suspend work to user space. So, the kernel already contains two mechanisms for doing hibernation, leaving no real chance for a third to be added.

There are clear disagreements about how much and which parts should be in the kernel versus in user space. Machek seems to think that nearly all of the task can be handled in user space, while Cunningham is in favor of the advantages—performance and being able to take advantage of in-kernel interfaces—of an all kernel approach. Wysocki is somewhere in the middle, outlining some of the advantages he sees in the in-kernel solution:

A bigger disconnect, though, is how to proceed. Cunningham would like to see TuxOnIce merged whole as a parallel alternative to swsusp, with an eye to eventually replacing and removing swsusp. Machek and Wysocki are not terribly interested in replacing swsusp, they would rather see incremental improvements—many coming from the TuxOnIce code—proposed and merged. On the one hand, Cunningham has an entire subsystem that he would like to see merged, while the swsusp folks have a subsystem—used by most distributions for hibernation—to maintain.

Cunningham recently posted an RFC for merging TuxOnIce "with a view to seeking to get it merged, perhaps in 2.6.31 or .32 (depending upon what needs work before it can be merged) and the willingness of those who matter". That was met with a somewhat heated reply by Machek. But Wysocki was quick to step in to try to avoid the flames:

After Cunningham agreed, the discussion turned to how to work together, which is where it seems to have hit an impasse. Wysocki and Cunningham, at least, see some clear advantages in the TuxOnIce code, but, contrary to Cunningham's wishes, having it merged wholesale is likely not in the cards. Cunningham describes his plan as follows:

Not surprisingly, Wysocki and Machek see things differently. Machek is not opposed to bringing some of TuxOnIce into the mainline: "If we are talking about improving mainline to allow tuxonice functionality... then yes, that sounds reasonable." Wysocki lays out an alternative plan that is much more in keeping with traditional kernel development strategies:

But, as Cunningham continues pushing for help in getting TuxOnIce merged alongside swsusp, Wysocki points out that it requires a great deal of review to get a huge (10,000+ lines of code) set of patches accepted: "That would take lot of work and we'd also have to ask many other busy people to do a lot of work for us". Cunningham seems to be under the misapprehension that kernel hackers will be willing to merge a subsystem that duplicates another without a clear overriding reason. Easing what he sees as a necessary transition from swsusp to TuxOnIce is not likely to be that compelling.

It is clearly frustrating for Cunningham to have a working solution but be unable to get it into the kernel. But it is a direct result of working out of the tree and then trying to present a solution when the kernel has gone in a different direction. It is a common mistake that folks make when dealing with the kernel community. Ray Lee provides a nice answer to Cunningham's frustrations, which points to IBM's device mapper contribution that suffered from a similar reaction. Lee notes that Wysocki has offered extremely valuable assistance:

At one point, Cunningham pointed to the SL*B memory allocators as an example of parallel implementations that are all available in the mainline. Various folks responded that memory allocators are fairly self-contained, unlike TuxOnIce. Furthermore, as Pekka Enberg notes: "Yes, so please don't make the same mistake we did. Once you have multiple implementations in the kernel, it's extremely hard to get rid of them."

There has been a bit of discussion about the technical aspects of the TuxOnIce patch, mostly centering on the way that it frees up memory to allow enough space to create a suspend image, while still adding the contents of that memory to the suspend image. By relying on existing kernel behavior, which is not necessarily guaranteed for the future, TuxOnIce can save nearly all of the memory contents, whereas swsusp dumps caches and the like to create enough memory to build the suspend image. That means that performance after a resume operation may be impacted as those caches are refilled. Overall, though, the main focus of the discussion has been the way forward; so far, there has been little progress on that front.

This is not the first time that TuxOnIce has gotten to this point. In its earlier guise as swsusp2, Cunningham made several attempts to get it into the mainline. In March of 2004, Andrew Morton asked that it be broken down into smaller, more easily digested, chunks. The same thing happened again near the end of 2004 when Cunningham proposed adding swsusp2 in one big code ball. It doesn't end there, either, between then and now the same request has been made; at this point one might guess that Cunningham simply isn't willing to do things that way.

There is a real danger that the TuxOnIce features that its users like could be lost—or remain out-of-tree—if something doesn't give. Either Cunningham has to recognize that the only plausible way to get TuxOnIce into the kernel is via the normal kernel development path, or someone else has to pick it up and start that process themselves. With no one (other than Cunningham) pushing for its inclusion, there simply is no other way for it to get into the mainline.