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@redhat.com>