"Current Linux versions can enter suspend-to-RAM just fine, but only can do it on explicit request. But suspend-to-RAM is important, eating something like 10% of [the] power needed [compared to an] idle system. Starting suspend manually is not too convenient," began Pavel Machek, describing an idea he referred to as Sleepy Linux. He continued, "[starting suspend manually] is not an option on multiuser machines, and even on single user machines some things are not easy: 1) Download this big chunk in Mozilla, then go to sleep; 2) Compile this, then go to sleep; 3) You can sleep now, but wake me up in 8:30 with mp3 player". Pavel provided a simple not-fully-functional patch, then described his proposed solution:
"Today's hardware is mostly capable of doing better: with correctly set up wakeups, machine can sleep and successfully pretend it is not sleeping -- by waking up whenever something interesting happens. Of course, it is easier on machines not connected to the network, and on notebook computers."
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."
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.