[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87644rcc7a.fsf@jbms.ath.cx>
Date: Wed, 11 Jul 2007 09:16:41 -0400
From: Jeremy Maitin-Shepard <jbms@....edu>
To: Nigel Cunningham <nigel@...el.suspend2.net>
Cc: Miklos Szeredi <miklos@...redi.hu>, rjw@...k.pl, a1426z@...ab.com,
jeremy@...p.org, pavel@....cz, nickpiggin@...oo.com.au,
linux-kernel@...r.kernel.org, akpm@...ux-foundation.org
Subject: Re: Hibernation Redesign
Nigel Cunningham <nigel@...el.suspend2.net> writes:
[snip]
> No other _proper_ solutions have been proposed. Everyone who suggests removing
> the freezer also suggests implementing it all over again. It might be sending
> SIGSTOP to everything. It might be shifting the desk chairs around and
> creating a completely new kernel context, but they always have the same
> goal - stopping the existing activity, and they all come with their own
> issues (even if they're not obvious yet because the alternatives are
> currently vapourware to one extent or another).
I'll certainly admit the kexec idea is vaporware currently, but it does
differ in a significant way from freezer-based approaches, such that I
don't think it should be referred to as just another implementation of a
freezer. Specifically, it doesn't require that the "old kernel" be in a
"consistent" state to a greater extent than suspend to ram; it is the
case that all of the devices must be quiesced or shut down to some
extent, but doing this without races and deadlocks (and without the
freezer) is certainly very, very similar to what needs to be done for
suspend to ram, which will need to be solved anyway. Unlike the
existing hibernate approaches, however, it will not be necessary to use
any of the driver infrastructure once switched to the "save image"
kernel, and thus it will not matter what locks are held, for instance.
[snip]
--
Jeremy Maitin-Shepard
-
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