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

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

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

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.
         * must be updated  whenever adding code which uses LIBXL_HAVE_*
        #define LIBXL_API_VERSION 0x405000
        #include <libxl.h>

configuring etc.


Xen-devel mailing list



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