Re: [Minios-devel] [PATCH v4 0/<VARIOUS>] Begin to disentangle libxenctrl and provide some stable libraries

[Ian Campbell <ian.campbell@citrix.com>]

On Fri, 2015-11-20 at 11:07 +0000, Stefano Stabellini wrote:
> On Thu, 19 Nov 2015, Ian Campbell wrote:
> > On Thu, 2015-11-19 at 16:20 +0000, Stefano Stabellini wrote:
> > 
> > I'll just answer this bit, since it ties into your other answers, I
> > think.
> > 
> > > Does the Xen<->libxc interface need to be stable for
> > > libxendevicemodel
> > > to have a stable ABI?
> > 
> > We could:
> > 
> > 1) support multiple versions of Xen in a single library binary by
> > detecting
> > the Xen version and dispatch the right kind of domctl with the right
> > ABI
> 
> It doesn't look like we need to go that far, given that we can assume
> that libxendevicemodel and the hypervisor are the same version.

I don't think we necessarily can.

> > or:
> > 
> > 2) provide multiple copies of libxendevicemodel.so.1 (the SONAME of the
> > library), one per Xen release and require that the distro's scripting
> > to
> > arrange on boot that the dynamic linker finds the right one for the
> > version
> > of Xen you are actually running under right now.
> 
> Do distros support having multiple different Xen packages installed on
> the same system?  That would be where the difficulty comes from. If that
> is not a supported use case, then I don't see the problem.

Debian does support this and in general it is important for upgrades (i.e.
installing 4.8 while running 4.7 and then expecting to shut down VMs on
reboot etc), and also because people naturally like to keep the old version
as a fallback after an upgrade (like one typically does with the kernel
etc).

I think it is something we as upstream should be moving more towards, or at
least not making it more difficult.

> On the other hand if that is supported, then yes, they would also need
> to arrange scripts to link the right libxendevicemodel to
> libxendevicemodel.so.1.

Yes, they could do this, it seems to me like a pretty unusual and not very
friendly requirement to push onto the distros though.

> > Neither of them are as easy as just having the Xen<->libxc interface in
> > question be stable.
> > 
> > Also, consider a distro package, typically the qemu package would
> > depend on
> > libxendevicemodel.so.1 (in some way or another), but actually the
> > dependency would be on a version of libxendevicemodel.so associated
> > with a
> > version of Xen >= the running version (i.e. libxendevicemodel from 4.7
> > obviously won't know about the ABI of 4.8).
> 
> I think that's fine, as long as the ABI is stable and you only have one
> libxendevicemodel.so.1 in your system: the one provided by the running
> Xen package.

Thinking about this some more last night it occurred to me that the Xen 4.8
packages would necessarily require the corresponding libxendevicemodel to
be around through dependencies (which would be >= 4.8, not ==4.8 as they
would be for an unstable ABI library).

So even if we were doing the versioning dynamically at runtime in the
library and the user was booting 4.7 the prevailing libxendevicemodel.so
would be one which spoke both 4.7 and 4.8.

Ian.

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