[libvirt] [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?
Wei Liu
wei.liu2 at citrix.com
Wed Apr 13 13:28:55 UTC 2016
On Wed, Apr 13, 2016 at 10:26:54AM +0100, 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 ?
>
No, it doesn't.
> 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.
>
That's sensible.
Wei.
> Regards,
> Daniel
> --
> |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org -o- http://virt-manager.org :|
> |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
More information about the libvir-list
mailing list