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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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.

Ian.


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