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