[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1198722793.7320.15.camel@caritas-dev.intel.com>
Date: Thu, 27 Dec 2007 10:33:13 +0800
From: "Huang, Ying" <ying.huang@...el.com>
To: Vivek Goyal <vgoyal@...hat.com>
Cc: "Eric W. Biederman" <ebiederm@...ssion.com>,
Pavel Machek <pavel@....cz>, nigel@...el.suspend2.net,
"Rafael J. Wysocki" <rjw@...k.pl>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-pm@...ts.linux-foundation.org,
Kexec Mailing List <kexec@...ts.infradead.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3 -mm] kexec jump -v8
On Wed, 2007-12-26 at 20:57 -0500, Vivek Goyal wrote:
[...]
> > 9. Now, you are in the original kernel again. You can read/write the
> > memory image of kexeced kernel via /proc/kimgcore.
> >
>
> Why do we need two interfaces, /proc/vmcore and /proc/kimgcore? Can't
> we have just one say /proc/vmcore. Irrespective of what kernel you are
> in /proc/vmcore gives you the access to the memory of kernel which was
> previously booted.
In theory we can kexec another kernel even in a kexeced kernel, that is,
in kernel A kexec kernel B, and in kernel B kexec another kernel C. In
this situation, both /proc/vmcore and /proc/kimgcore has valid contents.
So I think, it may be better to keep two interfaces.
In fact, current kexec jump implementation use a dummy "jump back helper
image" in kexeced kernel to jump back to the original kernel. The "jump
back helper image" has no PT_LOAD segment, it is used to provide a
struct kimage (including control page, swap page) and entry point to
jump back.
Best Regards,
Huang Ying
--
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