[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1352285859.12977.45.camel@hastur.hellion.org.uk>
Date: Wed, 7 Nov 2012 11:57:39 +0100
From: Ian Campbell <ian.campbell@...rix.com>
To: Stefano Stabellini <stefano.stabellini@...citrix.com>
CC: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/arm: Fix compile errors when
drivers are compiled as modules.
On Wed, 2012-11-07 at 10:25 +0000, Stefano Stabellini wrote:
> 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@...cle.com>
>
> 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.
On x86 these functions are static inline (all of them, I think) so
exporting them is not necessary or possible.
I don't think you can export from a .S, otherwise the obvious answer
would be to integrate it with the macro in hypercall.S.
Possibly mad idea: auto-generate hypercall.[Sc] (.S=stubs & .c=exports)
from include/xen/interface/xen.h:HYPERVISOR_* ?
(Aside: the whitespace in hypercall.S is a bit fubarred, wrt the line
wrapping in the macros)
Ian.
--
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