On 13/04/16 10:26, 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. IOW, we'd only need to update the > define for LIBXL_API_VERSION when we merge patches that actually need > the newer functionality. Oh, right -- yes, if that's the libvirt development model then it makes more sense to do what works best with that model to make sure each release has an appropriate LIBXL_API_VERSION. On reflection, it's probably a better idea even from a Xen development perspective. I was originally thinking that it would be nice to have the testing automatically flag up an update in libxl that could use a corresponding update in libvirt. But in practice, since we use these tests as a push-gate, having changesets in the xen development branch which break against libvirt master but require changes in libvirt master to fix is actually causes a fair amount of hassle. It might be useful for the XenProject to have a non-pushgate test which tests libvirt without a LIBXL_API_VERSION, just to flag things up, but that's something we can sort out on our side with a sed script. Thanks, -George -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list