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). [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.] _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
