[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |