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

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Tue, 2006-12-12 at 17:13 +0100, Gerd Hoffmann wrote:
> 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.

You mean the versions for arch's other than i386 and x86_64? 
arch/{x86_64,i386}/kernel/machine_kexec.c are both in the sparse tree
already.

If you are adding the function table to all architectures then you are
right, changing kernel/sys.c is much simpler. I thought the function
table was an implementation detail on i386 and x86_64 only.

Ian.


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