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

Re: [Xen-devel] [PATCH 2/2] xen/arm: Fix compile errors when drivers are compiled as modules.



On Wed, 7 Nov 2012, Ian Campbell wrote:
> 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@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.
> 
> On x86 these functions are static inline (all of them, I think) so
> exporting them is not necessary or possible.

What I meant is that on x86 we could move some of the hypercalls out of
hypercall.h.
That would be similar to the split that this patch is introducing.


> 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.

yeah..


> 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)
 
I would leave this idea aside for the moment :)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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