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

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


 


Rackspace

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