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@suse.com> 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