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

Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of libvirt

On Fri, 2012-02-24 at 12:18 +0000, Ian Jackson wrote:
> Jim Fehlig writes ("Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile 
> error of libvirt"):
> > The libvirt libxl driver doesn't use libxc directly. AFAICT, the problem
> > is that libxl.h includes <xen/sysctl.h>, which has this
> > 
> > #if !defined(__XEN__) && !defined(__XEN_TOOLS__)
> > #error "sysctl operations are intended for use by node control tools only"
> > #endif
> > 
> > Without the defines, Bamvor is hitting the #error directive.
> I see.  Hmm.  I have investigated further and:
> xl.c contained #include <xenctrl.h> which is definitely very wrong.
> when I
>  (a) #undef __XEN_TOOLS__ at the top of xl.c
>  (b) remove that
> I can reproduce the error in-tree.

Doing this with the two patches I sent yesterday works. (I resewnt them
at the head of my repost of the "libxl: improved handling for default
values in API" series.

We should arrange for xl*.c to not have __XEN_TOOLS__ defined though.

-D__XEN_TOOLS__ is part of the base CFLAGS defined in tools/Rules.mk but
perhaps we could add -U__XEN_TOOLS__ to the xl specific cflags?

> I'm unsure as to whether we should expect libxl callers include
> <xen/sysctl.h>.  I think my view is that including these Xen public
> headers for things like Xen sysctl numbers, scheduler parameter
> numbers, etc., is fine.  Ian, what do you think ?
> But we definitely need to do something to stop libxl callers,
> including xl, including xenctrl.h.

We can stop xl by just not doing it (TM), for other callers of libxl --
well, we say you shouldn't need it for toolstack operations and that
libxl should provide all the functionality but if they _really_ want to
ignore that...

Also a toolstack may have functionality which is not considered
"toolstack functionality" per the remit of libxl and for which they wish
to use xenctrl directly. e.g. perhaps they communicate with a guest
agent using their own shared ring protocol for which they require the
ability to map domain memory.


Xen-devel mailing list



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