Thread (51 messages) 51 messages, 8 authors, 2007-02-14

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

From: Zachary Amsden <hidden>
Date: 2007-02-14 01:06:44
Also in: lkml, xen-devel

Jeremy Fitzhardinge wrote:
quoted hunk ↗ jump to hunk
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
impact.

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 <redacted>
Signed-off-by: Chris Wright <redacted>
Signed-off-by: Jeremy Fitzhardinge <redacted>

===================================================================
--- a/arch/i386/kernel/paravirt.c
+++ b/arch/i386/kernel/paravirt.c
@@ -596,6 +596,123 @@ static int __init print_banner(void)
 	return 0;
 }
 core_initcall(print_banner);
+
+unsigned long paravirt_save_flags(void)
+{
+	return paravirt_ops.save_fl();
+}
+EXPORT_SYMBOL(paravirt_save_flags);
+
+void paravirt_restore_flags(unsigned long flags)
+{
+	paravirt_ops.restore_fl(flags);
+}
+EXPORT_SYMBOL(paravirt_restore_flags);
+
+void paravirt_irq_disable(void)
+{
+	paravirt_ops.irq_disable();
+}
+EXPORT_SYMBOL(paravirt_irq_disable);
+
+void paravirt_irq_enable(void)
+{
+	paravirt_ops.irq_enable();
+}
+EXPORT_SYMBOL(paravirt_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.

Zach
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help