[libvirt] [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?

[George Dunlap]

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 at 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