"The following three patches are intended to start the redesign of the suspend and hibernation framework for devices," began Rafael Wysocki. He noted that the first patch introduces new callbacks for suspend and hibernation, while the other two patches implement the new suspend and hibernation callbacks for the platform and PCI bus types. In describing the first patch in the series, he noted that previous callbacks were being phased out, explaining:

"The main purpose of doing this is to separate suspend (aka S2RAM and standby) callbacks from hibernation callbacks in such a way that the new callbacks won't take arguments and the semantics of each of them will be clearly specified. This has been requested for multiple times by many people, including Linus himself, and the reason is that within the current scheme if ->resume() is called, for example, it's difficult to say why it's been called (ie. is it a resume from RAM or from hibernation or a suspend/hibernation failure etc.?).

"The second purpose is to make the suspend/hibernation callbacks more flexible so that device drivers can handle more than they can within the current scheme. For example, some drivers may need to prevent new children of the device from being registered before their ->suspend() callbacks are executed or they may want to carry out some operations requiring the availability of some other devices, not directly bound via the parent-child relationship, in order to prepare for the execution of ->suspend(), etc."

Issues reported during the suspend-to-disk process lead Linux creator Linus Torvalds to suggest, "please - just make the f*cking suspend-to-disk use other routines already. 99% of all hardware needs to do exactly *nothing* on suspend-to-disk, and the ones that really do need things tend to need to not do a whole lot." He went on to explain why sharing the code path for suspend-to-disk and freezing to RAM is wrong:

"For example, the 'freeze' action for USB (which is one of the hardest things to suspend) should literally be something like just setting the controller STOP bit, and waiting for it to have stopped. The 'unfreeze' should be to just clear the stop bit, while the 'restart' should be just a controller reset to use the current memory image. NONE OF THIS HAS ABSOLUTELY ANYTHING TO DO WITH SUSPEND. It never did. I've told people so for years. Maybe actually seeing the problems will make people realize."

Linus also noted another advantage to having separate code paths for the two actions, "the other issue is that I've long wanted to make sure that when people fix suspend-to-ram, they don't screw up suspend-to-disk by mistake and vice versa." During the discussion, Rafael Wysocki noted that he would be fixing this up presently, "I'm already convinced, really. :-)"

"The following patches add a new testing facility for suspend and hibernation," noted Rafael J. Wysocki. He continued, "the first patch adds the possibility to test the suspend (STD) core code without actually suspending, which is useful for tracking problems with drivers etc. The second one modifies the hibernation core so that it can use the same facility (it's a bit more powerful than the existing hibernation test modes, since they really can't test the ACPI global methods)."

The testing facility introduces a new /sys/power/pm_test_level attribute, accepting a number from 1 to 5, with each value simulating a different level of the suspend or hibernation code. Rafael explained: "5 - test the freezing of processes; 4 - test the freezing of processes and suspending of devices; 3 - test the freezing of processes, suspending of devices and platform global control methods; 2 - test the freezing of processes, suspending of devices, platform global control methods and the disabling of nonboot CPUs; 1 - test the freezing of processes, suspending of devices, platform global control methods, the disabling of nonboot CPUs and suspending of platform/system devices". He added, "if a suspend is started by normal means, the suspend core will perform its normal operations up to the point indicated by the test level. Next, it will wait for 5 seconds and carry out the resume operations needed to transition the system back to the fully functional state." Rafael noted that setting pm_test_level to 0 disables the testing facility.

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

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

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