Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751674Ab1FIOPM (ORCPT ); Thu, 9 Jun 2011 10:15:12 -0400 Received: from router-fw.net-space.pl ([89.174.63.77]:36382 "EHLO router-fw.net-space.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751556Ab1FIOPI (ORCPT ); Thu, 9 Jun 2011 10:15:08 -0400 Date: Wed, 8 Jun 2011 18:04:45 +0200 From: Daniel Kiper To: Ian Campbell Cc: Daniel Kiper , "konrad.wilk@oracle.com" , "vgoyal@redhat.com" , "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" Subject: Re: kexec/kdump for Xen - implementation question Message-ID: <20110608160445.GA6091@router-fw-old.local.net-space.pl> References: <20110606160434.GA26021@router-fw-old.local.net-space.pl> <1307442566.775.555.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1307442566.775.555.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.3.28i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2122 Lines: 54 On Tue, Jun 07, 2011 at 11:29:26AM +0100, Ian Campbell wrote: > On Mon, 2011-06-06 at 17:04 +0100, Daniel Kiper wrote: > > Hi, > > > > Currently, I am working on kexec/kdump for Xen with emphasis on dom0 > > implementation issues. After reviewing relevant Xen Linux Kernel > > Ver. 2.6.18 code I realized (as I expected) that original kexec/kdump > > in mainline kernel should be extensively amended. Further, after some > > discussion with Konrad Rzeszutek Wilk and Ian Campbell it was clear > > for me that it could be done in a few diffrent ways. Due to this facts > > I decided to establish general implementation details with LKML and > > Xen-devel community to avoid extensive code rewrite in case my own > > proposal would not be accepted. > > > > Now I think about four solutions. I will present them in order of my > > preference. However, if you have another soultions to that problem > > please drop me a line. > > > > 1) Currently existing kexec/kdump implementation should be amended > > by adding Xen specific code mainly in arch/i386. It should look > > like: > > > > void machine_kexec(struct kimage *image) > > { > > #ifdef CONFIG_XEN > > if (xen_initial_domain()) { > > ... > > Xen specific code > > ... > > } > > #endif > > > > ... > > generic kexec/kdump code > > ... > > } > > This is about the ugliest way to do things and should be avoided. I think that in this case it is to some extent. I decided put this solution before struct machine_kexec_ops solution because this (let say conditional solution) touches only x86 code (and if it be required IA-64). struct machine_kexec_ops proposal require changes for 8 archs. I am not sure it could be accepted by kexec/kdump and relevant archs maintainers quickly. However, I think that struct machine_kexec_ops is better as longterm solution. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/