[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1313760998.3858.32.camel@br98xy6r>
Date: Fri, 19 Aug 2011 15:36:38 +0200
From: Michael Holzheu <holzheu@...ux.vnet.ibm.com>
To: Vivek Goyal <vgoyal@...hat.com>
Cc: Simon Horman <horms@...ge.net.au>, oomichi@....nes.nec.co.jp,
linux-s390@...r.kernel.org, mahesh@...ux.vnet.ibm.com,
heiko.carstens@...ibm.com, linux-kernel@...r.kernel.org,
hbabu@...ibm.com, ebiederm@...ssion.com, schwidefsky@...ibm.com,
kexec@...ts.infradead.org
Subject: Re: [patch 0/3] kdump: Add external kdump entry point for s390
stand-alone dump tools
Hello Vivek,
On Fri, 2011-08-19 at 09:20 -0400, Vivek Goyal wrote:
> On Fri, Aug 19, 2011 at 02:53:20PM +0200, Michael Holzheu wrote:
>
> [...]
> > > although I am a little unclear about the status of the kernel side of
> > > things. Please let me know if you would like me to merge the kexec-tools
> > > patches now or wait a bit (for an updated version?).
> >
> > I think that we are almost done with the discussion. I will send you my
> > current kexec-tools patches and would be glad, if you could integrate
> > them now.
>
> I guess kexec-tools integration will make more sense once kernel patches
> show up atleast in one maintainer's subtree.
The s390 kexec-tools kdump code will inactive as long a kernel shows
"Crash kernel" in /proc/iomem. So IMHO there is little risk to integrate
the code.
> Also in kernel patches, atleast we need to resolve the issue of arch
> specific kmap(), kunmap() calls so that we don't have to make
> kimage_load_crash_segment() arch specific.
As I told in my last mail we will do this later. So I think there are
currently no more open issues, correct?
Michael
--
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