Cc: Nigel Cunningham <ncunningham@...>, <nigel@...>, Pavel Machek <pavel@...>, Huang, Ying <ying.huang@...>, Eric W. Biederman <ebiederm@...>, Jeremy Maitin-Shepard <jbms@...>, <linux-kernel@...>, <linux-pm@...>, Kexec Mailing List <kexec@...>, Len Brown <lenb@...>
Hi Andrew,
On Friday, 21 September 2007 03:41, Andrew Morton wrote:
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.]
-
