linux-kernel - Re: Hibernation considerations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 17 Jul 2007 08:29:25 -0700 (PDT)
From:	david@...g.hm
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	Alan Stern <stern@...land.harvard.edu>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"Huang, Ying" <ying.huang@...el.com>,
	Jeremy Maitin-Shepard <jbms@....edu>,
	Kyle Moffett <mrmacman_g4@....com>,
	Nigel Cunningham <nigel@...el.suspend2.net>,
	Pavel Machek <pavel@....cz>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	Al Boldi <a1426z@...ab.com>
Subject: Re: Hibernation considerations

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@...g.hm 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.

David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/