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."

Ying Huang continues to work on his kexec-based hibernation patches. Currently only supporting the i386 architecture, Ying notes, "the setup of hibernation/restore is fairly complex. I will continue working on simplifying." Following up to the latest round of kexec-based hibernation patches posted to the Linux Kernel mailing list it was asked how performance would compare to other hibernation solutions. Ying suggested that with not-yet implemented optimizations it should offer comparable performance:

"In general, for kexec based hibernation, what increases hibernation/wakeup time: One extra Linux boot is needed to hibernate and wakeup. What decreases hibernation/wakeup time: Most hibernation/wakeup work is done in full functional user space program, so it is possible to do some optimization, such as parallel compression.

"So, I think the kexec based hibernation may be slower than original implementation in general. In this prototype implementation, the hibernation/wakeup time is much longer than original hibernation/wakeup implementation. But it has much to be optimized and I think it can approach the speed of the original implementation after optimization."

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."

"Since many alternative approaches to hibernation are now being considered and discussed," Rafael Wysocki began on the lkml, "I thought it might be a good idea to list some things that in my not so humble opinion should be taken care of by any hibernation framework. They are listed below, not in any particular order, because I think they all are important." He continued with the following list, including a paragraph discussing each: "filesystems mounted before the hibernation are untouchable; swap space in use before the hibernation must be handled with care; there are memory regions that must not be saved or restored; the user should be able to limit the size of a hibernation image; hibernation should be transparent from the applications' point of view; state of devices from before hibernation should be restored, if possible; on ACPI systems special platform-related actions have to be carried out at the right points, so that the platform works correctly after the restore; hibernation and restore should not be too slow; hibernation framework should not be too difficult to set up." Rafael went on to summarize:

"In my opinion any hibernation framework that doesn't take the above requirements into account in any way will be a failure. Moreover, the existing frameworks fail to follow some of them too, so I consider all of these frameworks as a work in progress. For this reason, I will much more appreciate ideas allowing us to improve the existing frameworks in a more or less evolutionary way, then attempts to replace them all with something entirely new."

Offering a potential alternative to the existing suspend and restore implementations in the Linux Kernel, Ying Huang posted a patch utilizing kexec, "kexec based hibernation has some potential advantages over uswsusp and suspend2. " He listed two such potential advantages, "the hibernation image size can exceed half of memory size easily," and, "the hibernation image can be written to and read from almost anywhere, such as a USB disk [or] NFS." He described the feature implemented by his patch as "jumping from a kexeced kernel to the original kernel", allowing someone to first boot from one kernel, then to kexec another crashdump kernel in reserved memory and run from it for a while, and finally to "jump back" to the original kernel.

Andrew Morton replied to the idea very positively, "this sounds awesome. Am I correct in expecting that ultimately the existing hibernation implementation just goes away and we reuse (and hence strengthen) the existing kexec (and kdump?) infrastructure? And that we get hibernation support almost for free on all kexec (and relocatable-kernel?) capable architectures? And that all the management of hibernation and resume happens in userspace?" He went on to ask, "how close do you think all this is to being a viable thing?" Ying replied, "the kexec jump is the first step, maybe the simplest step. There are many other issues to be resolved, at least the following ones," going on to list a series of steps that still have to be implemented before kexec based hibernation would be a viable option.