Yet another approach to software suspend

Yet another approach to software suspend

Posted Jul 22, 2007 10:17 UTC (Sun) by i3839 (guest, #31386)
In reply to: Yet another approach to software suspend by dlang
Parent article: Yet another approach to software suspend

Why let the kexec kernel do the restore instead of the boot kernel? As I see it there are two cases:

- The normal kernel and the kexec kernels share a kernel image. In this case the boot kernel just needs to allocate mem in the reserved area and kexec to the restored kernel when it's done restoring the image.

- They have two different kernel images. Now the bootup kernel needs to be loaded in the reserved area. Though this can be hard as the bootloader loads the kernel, so yes, in this case doing two kexeces seems simpler, though that would slow down the restore.

It's unclear what the ACPI hibernate mode does, but I guess it lets the bios boot up the machine quicker because it skips some hardware init stuff or something. So you'd want to support this as good as possible anyway, assuming it makes sense, no matter what else you do.

And the kexec approach also depends on the hardware state because the restored image depends on it. Only thing that kexec does well is making a good snapshot, but it doesn't solve the hardware side of it.

(Which could cause complications, because that state might be changed by loading the image.)

So no matter what approach is used (kexec, freezer, ...), 90% of the work will always be the suspend/hibernate/resume/wake-up functions in the drivers. Same for most problems caused.

If the current restore method works fine, why not continue using that?

---

(Log in to post comments)