On Tue, 17 Jul 2007, Rafael J. Wysocki wrote:
On Tuesday, 17 July 2007 17:29, david@xxxxxxx wrote:
On Tue, 17 Jul 2007, Rafael J. Wysocki wrote:
On Tuesday, 17 July 2007 16:15, Alan Stern wrote:
On Mon, 16 Jul 2007 david@xxxxxxx wrote:
I agree, it would be good to have a non-ACPI-specific hibernation mode,
something which would look to ACPI like a normal shutdown. But I'm not
so sure this is possible.
why would it not be possible?
I can't think of anything much more frustrating then thinking that I
suspended a system and then discovering that becouse the battery went dead
(a complete power loss) that the system wouldn't boot up properly. to me
this would be a fairly common condition (when I'm mobile I use the machine
until I am out of battery, then stop and it may be a long time (days)
before I can charge the thing up again) this would not be a reliable
suspend as far as I'm concerned.
for suspend-to-ram you have to worry about ACPI states and what you are
doing with them, for suspend-to-disk you can ignore them and completely
power the system off instead.
If the only problem with doing this would be lack of wakeup support
then I'm all for it. There must be a lot of people who would like
their computers to hibernate with power drain as close to 0 as possible
and who don't care about remote wakeup. In fact they might even prefer
not to have wakeup support, so the computer doesn't resume at
unexpected times.
I'm afraid of one thing, though.
If we create a framework without ACPI (well, ACPI needs to be enabled in the
kernel anyway for other reasons, like the ability to suspend to RAM) and then
it turns out that we have to add some ACPI hooks to it, that might be difficult
to do cleanly.
doing suspend-to-ram should be orthoginal to doing hibernate-to-disk. some
people will want both, some won't.
at the moment kexec doesn't work with ACPI, that is a limitation that
should be fixed, but makeing it able to work with ACPI enabled doesn't
mean that it needs to be changed to depend on ACPI and it especially
doesn't mean that it should pick up the limitations of the existing ACPI
based hibernation approaches.
if there is no ACPI on the system it should work, if ther is ACPI on the
system it should still work.
Thus, it seems reasonable to think of the ACPI handling in advance.
but don't become dependant on ACPI.
Not dependent, but with the possibility of ACPI support taken into account.
Arguably you can create a framework that, for example, will not allow the user
to adjust the size of the image, but then adding such a functionality may
require you to change the entire design. Same thing with ACPI.
I would rather avoid such pitfalls, if I could.
Ok, what is it that you think ACPI fundamentally changes in this process?
keep in mind that we are not makeing the assumption that the hardware
will remain powered (even a little bit), or the assumption that nothing
else will run on the hardware (eliminating any possibility that the
hardware is in a known ACPI state)
David Lang
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
