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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@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 ?
> 

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

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]