Message-Id: <200707171802.30903.rjw@sisk.pl>
Date:	Tue, 17 Jul 2007 18:02:29 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	david@...g.hm
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 Tuesday, 17 July 2007 17:29, david@...g.hm 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@...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.

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.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth
-
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/

Powered by blists - more mailing lists