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

[Jim Fehlig <jfehlig@xxxxxxxx>]

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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel