Re: [Xen-devel] [xen-unstable bisection] complete build-i386-libvirt

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2014-06-30 at 16:21 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable bisection] complete 
> build-i386-libvirt"):
> > Oh wait. If libvirt supports up to e.g. Xen 4.4 today then this option
> > would cause it to #define LIBXL_API_VERSION to that. But Xen 4.2 and 4.3
> > libxl wouldn't know what to do with it and would bail out.
> 
> Yes.
> 
> > We could deploy this flag only on the xen-unstable flights on the
> > assumption that this is the only place where the libxl API ought to be
> > changing.
> 
> Indeed.

I'd be a bit concerned that unless it was used in some "normal" scenario
this option would itself bit rot and we'd end up back where we started.

We can't just turn it on for the libvirt flight too, can we? I think
that would defeat the purpose (by causing Xen to rewind to the interface
which libvirt wants rather than the latest in order to provoke
breakage).

We could make the build-*-libvirt jobs build twice, once with and once
without. Perhaps in the libvirt flight only. Would that work?

Jim, do you think the idea of an option of this kind will fly at all
with you and the libvirt maintainers?

Perhaps something like:
        /* Force libxl to supply the latest API which we know about.
        This 
         * must be updated  whenever adding code which uses LIBXL_HAVE_*
         */
        #ifdef VIR_LIBXL_FORCE_LATEST_SUPPORTED_API
        #define LIBXL_API_VERSION 0x405000
        #endif
        
        #include <libxl.h>

Then osstest could CFLAGS=-DVIR_LIBXL_FORCE_LATEST_SUPPORTED_API when
configuring etc.

Ian.


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