Suspend and hibernation status report

Posted Jul 27, 2007 17:39 UTC (Fri) by NightMonkey (subscriber, #23051)
Parent article: Suspend and hibernation status report

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, after the separation of the suspend-specific and hibernation-specific device handling is done at the core and device class/device type/bus type level.

Yay! Does Nigel back this?

to post comments

Suspend and hibernation status report

Posted Jul 27, 2007 18:21 UTC (Fri) by rjw@sisk.pl (subscriber, #39252) [Link] (2 responses)

As far as I can say, he does.

Suspend and hibernation status report

Posted Jul 28, 2007 5:29 UTC (Sat) by moxfyre (guest, #13847) [Link] (1 responses)

Very impressive article! It sounds, well, extraordinarily complex... how much of this code can be shared with other kernel subsystems?

Would suspend/hibernation be easier to implement and maintain if BIOS/ACPI support were changed in some drastic way? Say, if we were all using LinuxBIOS or something like that?

Suspend and hibernation status report

Posted Jul 28, 2007 12:29 UTC (Sat) by rjw@sisk.pl (subscriber, #39252) [Link]

> Very impressive article! It sounds, well, extraordinarily complex... how
> much of this code can be shared with other kernel subsystems?

Unfortunately, not much. We do our best to reuse the existing code, but this is not always possible.

> Would suspend/hibernation be easier to implement and maintain if BIOS/ACPI
> support were changed in some drastic way? Say, if we were all using
> LinuxBIOS or something like that?

Well, it could help. For example, if the BIOS (I prefer to call it the platform firmware) were able to post the graphics adapters during a resume, such things like s2ram wouldn't be necessary. Also, if the platform firmware source code were known to us, it would be easier to program the kernel side of things.

On the other hand, there are some problems related to hibernation that have nothing to do with the platform firmware (memory management, the handling of tasks, image saving/loading).