[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m1ejaew7dm.fsf@ebiederm.dsl.xmission.com>
Date: Thu, 13 Mar 2008 17:07:17 -0600
From: ebiederm@...ssion.com (Eric W. Biederman)
To: "Rafael J. Wysocki" <rjw@...k.pl>
Cc: Alan Stern <stern@...land.harvard.edu>,
"Huang, Ying" <ying.huang@...el.com>, nigel@...el.suspend2.net,
Kexec Mailing List <kexec@...ts.infradead.org>,
linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
linux-pm@...ts.linux-foundation.org,
Vivek Goyal <vgoyal@...hat.com>
Subject: Re: [linux-pm] [PATCH -mm] kexec jump -v9
"Rafael J. Wysocki" <rjw@...k.pl> writes:
> From the ACPI compliance point of view it's better to do it this way. We need
> to put the devices into low power states anyway before "powering off" the
> system and we won't need to touch them for the second time if we do that
> in advance.
Interesting. From a kexec jump where we exit the kernel and then return
to it seem all that is required.
I will have to look at the ACPI case. That seems to be the lynch pin
of a couple of arguments for doing strange things: ACPI requires it.
> Still, it would be sufficient if we disconnected the drivers from the hardware
> and thus prevented applications from accessing that hardware.
My gut feeling is that except for a handful of drivers we could even
get away with simply implementing hot unplug and hot replug. Disks
are the big exception here.
Which suggests to me that it is at least possible that the methods we
want for a kexec jump hibernation may be different from an in-kernel
hibernation and quite possibly are easier to implement.
Eric
--
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