[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <45D260A2.4010200@vmware.com>
Date: Tue, 13 Feb 2007 17:06:42 -0800
From: Zachary Amsden <zach@...are.com>
To: Jeremy Fitzhardinge <jeremy@...p.org>
CC: Andi Kleen <ak@....de>, Andrew Morton <akpm@...l.org>,
linux-kernel@...r.kernel.org, virtualization@...ts.osdl.org,
xen-devel@...ts.xensource.com, Chris Wright <chrisw@...s-sol.org>,
Rusty Russell <rusty@...tcorp.com.au>
Subject: 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
> 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 <rusty@...tcorp.com.au>
> Signed-off-by: Chris Wright <chrisw@...s-sol.org>
> Signed-off-by: Jeremy Fitzhardinge <jeremy@...source.com>
>
> ===================================================================
> --- 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists