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

Re: [Xen-devel] kexec trouble



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.

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!).

 -- Keir


_______________________________________________
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®.