Ying Huang posted an updated version of his kexec based hiberation patches. Pavel Machek, one of the uswsusp maintainers, responsed favorably, suggesting, "seems like good enough for -mm to me." He went on to note that he didn't see the kexec patches being a hibernation solution anytime soon, but that the functinality was useful for other purposes such as simply dumping memory and continuing. TuxOnIce maintainer Nigel Cunningham added, "Andrew, if I recall correctly, you said a while ago that you didn't want another hibernation implementation in the vanilla kernel. If you're going to consider merging this kexec code, will you also please consider merging TuxOnIce?"

Andrew Morton explained what made the kexec solution attractive, "the theory is that kexec-based hibernation will mainly use preexisting kexec code and will permit us to delete the existing hibernation implementation. That's different from replacing it." Rafael Wysocki disagreed, pointing out that there was still quite a bit of work that kexec would have to do which would require more code in the kernel. He also pointed to the complexity of dealing with ACPI systems. Ying replied, "Yes. ACPI is a biggest issue of kexec based hibernation now. I will try to work on that. At least I can prove whether kexec based hibernation is possible with ACPI."

Rafael Wysocki posted a lengthy status report "describing the current state of development of the suspend and hibernation infrastructure: how it works, what known problems there are in it and what the future development plans are". Regarding future plans, Rafael noted, "the part of the suspend and hibernation code that should be taken care of first is the handling of devices. Namely, I think that we should first separate the hibernation-related handling of devices from the suspend-related handling of them in order to overcome limitations mentioned in Section IX. This also will be necessary if we want to try some new approaches to hibernation, such as the kexec-based one recently discussed on the LKML." He added, "the next thing that seems reasonable to do is to eliminate the freezing of tasks, described in Section VI, from the suspend and resume code, since the limitations related to it are regarded by many people as too restrictive." He went on to note:

"There also is the alternative hibernation framework TuxOnIce maintained by Nigel Cunningham, which is more feature-rich than the current in-kernel hibernation code. It therefore seems reasonable to incorporate at least some of the more advanced TuxOnIce features into the in-kernel code. I believe that by combining TuxOnIce with the current in-kernel hibernation implementation we can obtain a relatively simple, but powerful and solid hibernation framework, so I am going to work in this direction".

Ying Huang posted a new version of his hibernation patches that utilize kexec noting two changes, "1) the kexec jump implementation is put into the kexec/kdump framework instead of software suspend framework. The device and CPU state save/restore code of software suspend is called when needed; and 2) the same code path is used for both kexec a new kernel and jump back to original kernel." Andrew Morton noted that he was still interested however didn't intend to merge the patches right away, "I like the idea but I think I'll let people chat about it a bit more before looking at merging the patches, OK?" TuxOnIce maintainer Nigel Cunningham expressed some strong reservations:

"Please wait until you see a complete implementation that actually works. I'm sitting here quietly, following (and now breaking) the 'If you can't say anything positive, don't say anything at all' line because I think that the more into the implementation details people get, the uglier this is going to show itself to be. I'm perfectly willing to be proven wrong, but haven't seen anything so far that's even begun to convince me otherwise."

The 'Suspend2' project [story] has been renamed to 'TuxOnIce' Nigel Cunningham announced on the lkml, "this is for a couple of reasons: In recent discussions on LKML, the point was made that the word 'Suspend' is confusing. It is used to refer to both suspending to disk and suspending to ram. Life will be simpler if we more clearly differentiate the two. The name Suspend2 came about a couple of years ago when we made the 2.0 release and started self-hosting. If we ever get to a 3.0 release, the name could become even more confusing! (And there are already problems with people confusing the name with swsusp and talking about uswsusp as version 3!)."

Some concern was expressed that this move indicated that the rewritten suspend infrastructure was not being targetted for core inclusion. Nigel explained that this was not the case, "as far as I know, the desire on Rafael's part and mine is still to get at least some of the functionality merged. The only reason this isn't happening yet is that we're both busy with other aspects of the work. Rafael is focussing on infrastructure issues, I'm focussing on minimising the diff and finishing off cleaning up and adding comments to functions." Rafael Wysocki agreed, "my first target is to introduce a framework allowing drivers to have different callbacks for hibernation and suspend. Unfortunately, that turned out to require quite a lot of work - and time - to do."

Nigel Cunningham submitted his suspend2 patches [story] to the lkml for review and inclusion into Andrew Morton [interview]'s -mm tree [story]. Jens Axboe summarized the current roadblocks to merging suspend2, "now I haven't followed the suspend2 vs swsusp debate very closely, but it seems to me that your biggest problem with getting this merged is getting consensus on where exactly this is going. Nobody wants two different suspend modules in the kernel. So there are two options - suspend2 is deemed the way to go, and it gets merged and replaces swsusp. Or the other way around - people like swsusp more, and you are doomed to maintain suspend2 outside the tree."

Greg KH pointed out that the current focus with swsusp is to move the functionality from the kernel into userspace, called uswsusp, "Pavel and others have a working implementation and are slowly moving toward adding all of the 'bright and shiny' features that is in suspend2 to it (encryption, progress screens, abort by pressing a key, etc.) so that there is no loss of functionality." Nigel countered that only some of swsusp is being moved to userland, adding, "and there _is_ loss of functionality - uswsusp still doesn't support writing a full image of memory, writing to multiple swap devices (partitions or files), or writing to ordinary files. They're getting the low hanging fruit, but when it comes to these parts of the problem, they're going to require either smoke and very good mirrors (eg the swap prefetching trick), or simply refuse to implement them." Pavel Machek, maintainer of swsusp and uswsusp, replied item by item to Nigel's list of suspend2 advantages noting that uswsusp now has or soon will have the same capabilities. It was further noted that the submitted patches will need to be consolidated into logical pieces and resubmitted for proper review.