Re: [PATCH 2/2] xen/arm: Fix compile errors when drivers are compiledas modules.

[Stefano Stabellini]

On Tue, 6 Nov 2012, Konrad Rzeszutek Wilk wrote:
> We end up with:
> 
> ERROR: "HYPERVISOR_event_channel_op" [drivers/xen/xen-gntdev.ko] undefined!
> ERROR: "privcmd_call" [drivers/xen/xen-privcmd.ko] undefined!
> ERROR: "HYPERVISOR_grant_table_op" [drivers/net/xen-netback/xen-netback.ko] undefined!
> 
> and this patch exports said function (which is implemented in hypercall.S).
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>

Thank you very much for going out of your way to fix this issue (I am
currently at LinuxCon).


>  arch/arm/xen/enlighten.c |    5 +++++
>  1 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 59bcb96..96d969d 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -166,3 +166,8 @@ void free_xenballooned_pages(int nr_pages, struct page **pages)
>  	*pages = NULL;
>  }
>  EXPORT_SYMBOL_GPL(free_xenballooned_pages);
> +
> +/* In the hypervisor.S file. */
> +EXPORT_SYMBOL_GPL(HYPERVISOR_event_channel_op);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_grant_table_op);
> +EXPORT_SYMBOL_GPL(privcmd_call);
 
I think the patch is OK and I tested it: it fixes the issue reported
by Russell.
However I am wondering, does it actually make sense only to export 3
hypercalls among the set implemented in hypercall.S?
Maybe it does make sense only to export a subset, but I wouldn't
necessarly do the differentiation here, I would just export all the
hypercalls implemented in hypercalls.S.
In fact if we separate the hypercalls in two sets, I would like to
see a similar differentiation on x86 too.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/