Re: [libvirt] [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?
On 04/13/2016 03:09 AM, George Dunlap wrote:
On Tue, Apr 12, 2016 at 10:31 PM, Jim Fehlig <jfehlig(a)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.
Yes, agreed. In practice though folks want a new libvirt with the new Xen, which
is probably why no one has complained thus far.
I'll knock up a patch to set the LIBXL_API_VERSION to 0x040200. The only APIs
that have changed since 0x040200 are libxl_set_vcpuaffinity and
libxl_domain_create_restore, but libvirt does not use the changes (added
params). libvirt does use new libxl APIs added since Xen 4.2, but those aren't
tied to a specific LIBXL_API_VERSION.
Regards,
Jim