[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] kexec trouble


  • To: "Keir Fraser" <keir@xxxxxxxxxxxxx>
  • From: "Magnus Damm" <magnus.damm@xxxxxxxxx>
  • Date: Wed, 6 Dec 2006 18:08:03 +0900
  • Cc: Gerd Hoffmann <kraxel@xxxxxxx>, Xen devel list <xen-devel@xxxxxxxxxxxxxxxxxxx>, Magnus Damm <magnus@xxxxxxxxxxxxx>
  • Delivery-date: Wed, 06 Dec 2006 01:08:01 -0800
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=biuzsFt0CqTLwnC9CIWp/lIfvPIdnE4G7Q9RM6cuTOvA64kAOdQCsvL4vvmQ0xlw9aSuRj450fHHz2xm2XgcslR9QPGgPk1zrLLv+jSU+pqK0q2XNers+N4wPTv1G5Zjex2sF+pTcDzA/5QTgz3v1p/0ZuzZRECLidKvLOVEpbo=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

On 12/6/06, Keir Fraser <keir@xxxxxxxxxxxxx> wrote:
On 5/12/06 3:53 pm, "Magnus Damm" <magnus.damm@xxxxxxxxx> wrote:

>> I think we need either wrapper functions for machine_kexec_* functions
>> which dispatch to the correct function depending on the environment
>> (dom0 vs domU, later also native) or just make them function pointers to
>> archive the same effect.  Same goes for the KEXEC_ARCH_HAS_PAGE_MACROS
>> stuff.  IMHO "#ifdef CONFIG_XEN" should go away from the core code (i.e.
>> kernel/kexec.c).
>
> You mean for the paravirt stuff? Isn't paravirt basically a set of
> callbacks that you can register? If so, what is stopping us from
> registering a set of paravirt callbacks for the kexec code?

I think partly Gerd's point is that CONFIG_XEN in kernel/kexec.c will never
get merged upstream. Guaranteed.

Sure, I understand that. But I see this as an iterative process, where
the our code so far has been written to fit the current codebase. When
dom0 runs on paravirt and we can test the code then it should be
adjusted. It's kind of hard to write for something that doesn't yet
exist. =) So regardless how you do it, you still need to adjust your
code towards the new interface in the end - it's just a matter of how
much code you need to adjust.

I'm all for converting the code into using runtime checks or callbacks
if that is needed, and I would have done so in the first place if I'd
known that it was something that you guys wanted. But I didn't so we
used the simplest possible solution instead which was CONFIG_XEN.

The kexec/kdump patches are not very tidy in some respects like this. We
applied them now because the functionality is useful, but I don't think we
yet have the finished polished article. Also you got away with it because
the code changes were hidden in the patches/ directory, which you originally
said was simply backported code from 2.6.19 (not backported-and-hacked-on!).

The git-patches are backports. The other ones are not:

http://lists.xensource.com/archives/html/xen-devel/2006-10/msg01240.html

/ magnus

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.