On 9/21/07, Rafael J. Wysocki <rjw@xxxxxxx> wrote: > Hi Andrew, > > On Friday, 21 September 2007 03:41, Andrew Morton wrote: > > On Fri, 21 Sep 2007 11:19:59 +1000 Nigel Cunningham <ncunningham@xxxxxxxxxxx> wrote: > > > > > Hi. > > > > > > On Friday 21 September 2007 11:06:23 Andrew Morton wrote: > > > > On Fri, 21 Sep 2007 10:24:34 +1000 Nigel Cunningham > > > <nigel@xxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > > Hi Andrew. > > > > > > > > > > On Thursday 20 September 2007 20:09:41 Pavel Machek wrote: > > > > > > Seems like good enough for -mm to me. > > > > > > > > > > > > Pavel > > > > > > > > > > Andrew, if I recall correctly, you said a while ago that you didn't want > > > > > another hibernation implementation in the vanilla kernel. If you're going > > > to > > > > > consider merging this kexec code, will you also please consider merging > > > > > TuxOnIce? > > > > > > > > > > > > > The theory is that kexec-based hibernation will mainly use preexisting > > > > kexec code and will permit us to delete the existing hibernation > > > > implementation. > > > > > > > > That's different from replacing it. > > > > > > TuxOnIce doesn't remove the existing implementation either. It can > > > transparently replace it, but you can enable/disable that at compile time. > > > > Right. So we end up with two implementations in-tree. Whereas > > kexec-based-hibernation leads us to having zero implementations in-tree. > > Well, I don't quite agree. > > For now, the kexec-based approach is missing the handling of devices, AFAICS. > Namely, it's quite easy to snapshot memory with the help of kexec, but the > state of devices gets trashed in the process, so you need some additional code > saving the state of devices for you, executed before the kexec. > > Moreover, on ACPI systems the transition to the S4 sleep state and back to S0 > (working state) is more complicated than a system checkpointing, because we > are supposed to take the platform firmware into consideration in that case. > The more I think about this, the more it seems to me that it just can't be done > on top of kexec in a reasonable fashion. Of course, we could avoid handling > the ACPI S4, but that would leave some people (including me ;-)) with > semi-working hardware after the "restore". I don't think that's generally > acceptable in the long run. > > IMHO, for ACPI systems the way to go is to harden suspend to RAM (with s2ram > in place and the graphics adapters specifications from Intel and AMD released > we are in a good position to do that) and build the S4 transition mechanism > on top of that. It can be done easlily by adapting the current hibernation > code, but not on top of kexec (I'm afraid). Yes. ACPI is a biggest issue of kexec based hibernation now. I will try to work on that. At least I can prove whether kexec based hibernation is possible with ACPI. > [Besides, the current hibernation userland interface is used by default by > openSUSE and it's also used by quite some Debian users, so we can't drop > it overnight and it can't be implemented in a compatible way on top of the > kexec-based solution.] Best Regards, Huang Ying _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
