[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080711122131.b6461ab1.akpm@linux-foundation.org>
Date: Fri, 11 Jul 2008 12:21:31 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Vivek Goyal <vgoyal@...hat.com>
Cc: Huang Ying <ying.huang@...el.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Pavel Machek <pavel@....cz>, nigel@...el.suspend2.net,
"Rafael J. Wysocki" <rjw@...k.pl>, linux-kernel@...r.kernel.org,
linux-pm@...ts.linux-foundation.org,
Kexec Mailing List <kexec@...ts.infradead.org>
Subject: Re: [PATCH -mm 1/2] kexec jump -v12: kexec jump
On Tue, 8 Jul 2008 10:50:51 -0400 Vivek Goyal <vgoyal@...hat.com> wrote:
> On Mon, Jul 07, 2008 at 11:25:22AM +0800, Huang Ying wrote:
> > This patch provides an enhancement to kexec/kdump. It implements
> > the following features:
> >
> > - Backup/restore memory used by the original kernel before/after
> > kexec.
> >
> > - Save/restore CPU state before/after kexec.
> >
>
> Hi Huang,
>
> In general this patch set looks good enough to live in -mm and
> get some testing going.
>
> To me, adding capability to return back to original kernel looks
> like a logical extension to kexec functionality.
Exciting ;) It's much less code than I expected.
I don't think I understand the feature any more. Once upon a time we
thought that this might become a new and better (or at least
better-code-sharing) way of doing suspend-to-disk. How far are we from
that?
What are the prospects of supporting other architectures?
Who maintains kexec-tools, and are they OK with merging up the
corresponding changes?
Thanks.
--
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