Re: [Xen-devel] kexec trouble

["Magnus Damm" <magnus.damm@xxxxxxxxx>]

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