[Libvir] Linker dependancoes [Re: [kvm-devel] QEMU / KVM support in libvirt & virt-manager]

[Karel Zak]

On Sun, Feb 25, 2007 at 08:48:12PM +0000, Daniel P. Berrange wrote:
> See this thread on kvm-devel for a question about link time dependancies
> in libvirt. I'm not sure what the optimal approach is for us to deal with
> this is - just something we should think about in an idle moment...

 Definitely (... it would be best for FC7, no later.)

 The libvirt already uses exactly defined API (struct virDriver). I
 think it's a possible food for dlopen(). The rpm could be divided to
 multiple subpackages:

    libvirt.rpm
    libvirt-driver-xen.rpm
    libvirt-driver-qemu.rpm
    libvirt-driver-kvm.rpm

  Karel

> > > Yeah, we've not figured out exactly how to address that dependancy
> > > issue yet - the libvirt.so has to link to libxenstore as part of the
> > > Xen driver, so even if you only want to manage QEMU instances we still
> > > end up pulling in Xen. We're certainly going to make it possible to
> > > turn off the Xen stuff at compile time. Not clear how we'd address the
> > > RPM dep issue though because the Fedora builds of libvirt will include
> > > both Xen & QEMU support. Perhaps we'll have to try a dlopen() approach.
> > 
> > I would suggest a /usr/lib/libvirt/xen.so and a 
> > /usr/lib/libvirt/qemu.so, which are enumerated by reading 
> > /usr/lib/libvirt, and dlopen()ed by libvirt.so.  Only 
> > /usr/lib/libvirt/xen.so links to libxenstore.
> > 
> > That way, a third party can add a backend by dropping a .so into 
> > /usr/lib/libvirt, and libvirt.so itself has no backend-related 
> > dependencies -- it doesn't know anything concrete about the backends, in 
> > fact.

-- 
 Karel Zak  <kzak at redhat.com>