On Thursday, 15 of May 2008, Eric W. Biederman wrote:Well, you don't remove the power from devices doing that, do you? I was referring to the fact that you remove the power from devices after saving the image (ie. in the "poweroff" stage). Then, you initialize them and pass all that to the restored kernel and the question here is: (a) Should they be reinitialized before the restored kernel has a chance to access them? (b) If they should, what state they ought to be in when the restored kernel accesses them. That basically depends on how you're going to handle the resuming of devices, especially on the ACPI bus, in the restored kernel. If we are to follow ACPI, the answer to (a) is "no", except for devices used to read the image and it's better if the boot kernel doesn't touch ACPI at all. Then, the benefit of putting the system into S4 during the "poweroff" stage is that (a) the resume can be carried out faster and (b) the restored kernel may use some context preserved by the platform over the sleep state. Also, that allows you to use the wake up capabilities of some devices that need not be available from S5. In any case, however, I don't really think that doing the kexec jump before creating the image is really necessary. The kexec jump during resume is in fact very similar to what the current hibernation code does, but it's slightly more complicated. :-) Thanks, Rafael --
| Greg Kroah-Hartman | [PATCH 005/196] Chinese: add translation of SubmittingDrivers |
| Nick Piggin | [patch] my mmu notifier sample driver |
| Sean | Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching |
| Arjan van de Ven | [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in |
git: | |
| Antonio Almeida | HTB accuracy for high speed |
| Gerrit Renker | [PATCH 0/37] dccp: Feature negotiation - last call for comments |
| Jens Axboe | Re: [BUG] New Kernel Bugs |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
