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

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



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

----- Forwarded message from Avi Kivity <avi qumranet com> -----

> Date: Sun, 25 Feb 2007 18:48:44 +0200
> From: Avi Kivity <avi qumranet com>
> To: "Daniel P. Berrange" <berrange redhat com>
> CC: kvm-devel lists sourceforge net
> Subject: Re: [kvm-devel] QEMU / KVM support in libvirt & virt-manager
> 
> Daniel P. Berrange wrote:
> > On Sun, Feb 25, 2007 at 07:32:58AM +0200, Avi Kivity wrote:
> >   
> >> Daniel P. Berrange wrote:
> >>     
> >>> FYI, as of libvirt 0.2.0  and virt-manager 0.3.1 there is now 
> >>> (experimental!)
> >>> support for managing virtual machines running under QEMU or KVM 
> >>> virtualization
> >>> platforms, as well as the existing Xen support.
> >>>
> >> Great; as I see it hit FC6-updates I'll give it a shot.
> >>
> >> One thing I saw is that it pulls in Xen as part of the dependencies; 
> >> perhaps a libvirt-xen and libvirt-kvm subpackage split is called for?
> >
> > 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.
----- End forwarded message -----

Dan
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 


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