On 04/13/2016 03:09 AM, George Dunlap wrote: > On Tue, Apr 12, 2016 at 10:31 PM, Jim Fehlig <jfehlig@xxxxxxxx> wrote: >> Wei Liu wrote: >>> Hi libvirt maintainers, >> Sorry for the delay. Slowly catching up on mail after vacation... >> >>> Xen's control library libxenlight (libxl) requires application >>> (libvirt in this case) to explictily define LIBXL_API_VERSION. >> Where is this requirement written? :-) >> >>> This is >>> lacking at the moment so libvirt's libxl driver always gets the latest >>> APIs. >> IMO, that is what we want for upstream libvirt. Downstreams can choose a >> specific version if they want. > I think one of us isn't understanding the situation properly. Is it > not the case that currently, all releases of libvirt *will not > compile* against Xen 4.7 once it's released? So people downloading > and building libvirt will have to either 1) root around and try to > figure out what version of Xen it will build against, 2) manually add > in a #define *with the correct API version* to a header somewhere to > make it build properly, or 3) update to a version of libvirt that > supports the new api (which at the moment hasn't even been released > yet)? > > All of those options are completely unacceptable. Older versions of > libvirt should Just Work when compiled against newer versions of Xen. Yes, agreed. In practice though folks want a new libvirt with the new Xen, which is probably why no one has complained thus far. I'll knock up a patch to set the LIBXL_API_VERSION to 0x040200. The only APIs that have changed since 0x040200 are libxl_set_vcpuaffinity and libxl_domain_create_restore, but libvirt does not use the changes (added params). libvirt does use new libxl APIs added since Xen 4.2, but those aren't tied to a specific LIBXL_API_VERSION. Regards, Jim -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list