| |||||||||||||
|
| |||||||||||||
Yet another approach to software suspendYet another approach to software suspendPosted Jul 21, 2007 0:42 UTC (Sat) by i3839 (subscriber, #31386)In reply to: Yet another approach to software suspend by khim Parent article: Yet another approach to software suspend
I think you misunderstand me. With "machine bootup" I meant the hardware, I didn't mean that the kernel does a regular bootup.
The topic was returning from the kexec kernel, and I said it's not needed. Maybe you're right that doing a kexec is needed to cleanly restore the old kernel state, as doing it from the first kernel loaded is too ugly, but I still don't see any reason why there's a need to return from the kexeced kernel back to the original one. Why not just kexec to the restored, original kernel? (No matter to which point exactly.)
(Log in to post comments)
Yet another approach to software suspend Posted Jul 21, 2007 0:49 UTC (Sat) by i3839 (subscriber, #31386) [Link] (It makes going to s2ram after the image dump possible, then jumping back is required indeed. But not for plain hibernate.)
Yet another approach to software suspend Posted Jul 21, 2007 18:48 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link] there is contradictory information about how much work needs to be done for the restore
the current restore functions assume that all the hardware has been put into ACPI low-power mode or the restore image may not work
so the two options right now seem to be
the second approach isn't elegant, but doesn't depend on the state of the hardware.
Yet another approach to software suspend Posted Jul 22, 2007 10:17 UTC (Sun) by i3839 (subscriber, #31386) [Link] 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?
Yet another approach to software suspend Posted Jul 22, 2007 22:06 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link] Quote:If the current restore method works fine, why not continue using that?
becouse Rafael is telling everyone that if you completely power off the system the current restore method will not properly restore the box (most things should come up, but things will not be right)
|
|
||||||||||||