WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: [patch] Add kexec_ops & function pointers

Ian Campbell wrote:
>>> Hiding the indirections through the function table in the header via
>>> defines or inline functions would make things a lot cleaner in my
>>> opinion and as a bonus avoid this addition to the sparse tree.
>> No.  As machine_kexec() continues to exist (and is the default for
>> kexec_ops.kexec) you can't just turn that into a macro.  You have to
>> either fix the two callers (as done by the patch) or rename the function
>> to something different in arch/*/kernel/machine_kexec.c in order to be
>> able to reuse the name for the macro.
> 
> Yes you may need to rename some bits. I was thinking of a solution where
> you have foo_native, foo_xen0 and foo_xenU functions (or whatever) with
> an inline foo() which calls through the function table to the correct
> version.

Sure.  But renaming machine_kexec() to machine_kexec_native() or simliar
means touching a big bunch of files, namely
arch/{lots-of-directories-here}/kernel/machine_kexec.c.  I'd prefer to
touch only one (kernel/sys.c) to keep the number of changes in the xen
tree small.

We'll have to see how we solve that finally, most likely it isn't the
final solution anyway.  paravirt is still some way to go, we have to
upgrade to 2.6.20-rc1 first, and even that gives us paravirt for x86_32
only, not yet x86_64 ...

cheers,
  Gerd

-- 
Gerd Hoffmann <kraxel@xxxxxxx>

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