On 04/13/2016 03:26 AM, Daniel P. Berrange wrote: > On Wed, Apr 13, 2016 at 10:09:16AM +0100, 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. >> >> I think it does make sense to have the libvirt development branch not >> specify an API version; but when it branches for release, it should >> set LIBXL_API_VERSION to whatever the current version is at the time >> of the branch. > FYI, libvirt doesn't do branching for releases - we always just cut the > release straight from the master branch. We only actually create branches > on demand, when we find we want to backport fixes to a previous release. > > Does libvirt master really need to always use the latest API version ? > > It feels like libvirt could just set LIBXL_API_VERSION to the lowest > version it requires in order to get the functionality we know we are > able to currently build against. I think that is a good idea too. I've sent a patch setting LIBXL_API_VERSION to 0x040200 https://www.redhat.com/archives/libvir-list/2016-April/msg00771.html Changes made to the APIs since 0x040200 (params added to libxl_domain_create_restore and libxl_set_vcpuaffinity) are currently not used by libvirt. Regards, Jim -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list