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

[Xen-devel] Re: [patch 10/21] Xen-paravirt: Name: dont export paravirt_ops structure, do individual functions

Jeremy Fitzhardinge wrote:
Wrap the paravirt_ops members we want to export in wrapper functions.
Since we binary-patch the critical ones, this doesn't make a speed

I moved drm_follow_page into the core, to avoid having to wrap the
various pte ops.  Unlining kernel_fpu_end and using that in the RAID6
code would remove the need to export clts/read_cr0/write_cr0 too.

Signed-off-by: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
Signed-off-by: Chris Wright <chrisw@xxxxxxxxxxxx>
Signed-off-by: Jeremy Fitzhardinge <jeremy@xxxxxxxxxxxxx>

--- a/arch/i386/kernel/paravirt.c
+++ b/arch/i386/kernel/paravirt.c
@@ -596,6 +596,123 @@ static int __init print_banner(void)
        return 0;
+unsigned long paravirt_save_flags(void)
+       return paravirt_ops.save_fl();
+void paravirt_restore_flags(unsigned long flags)
+       paravirt_ops.restore_fl(flags);
+void paravirt_irq_disable(void)
+       paravirt_ops.irq_disable();
+void paravirt_irq_enable(void)
+       paravirt_ops.irq_enable();

This turned out really hideous looking to me. Can't we split the struct into GPL'd and non-GPL'd functions instead? We still have the same granularity, and none of this function call to an indirect function call nonsense.


Xen-devel mailing list



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