Re: [Qemu-devel] RFC: DSO (dynamic shared objects) support

[Daniel P. Berrange]

On Tue, Jun 18, 2013 at 02:17:08PM +0200, Laszlo Ersek wrote:
> On 06/18/13 13:37, Michael Tokarev wrote:
> 
> > Next, and this is the most complex part.  The build system for
> > modules, and configuring it.   I heard there were plans to use
> > something like kbuild system for that, has anything been done
> > in this context?
> 
> Sorry for responding separately... Some module/symbol versioning will be
> necessary, as the binding will be delayed until runtime, and users
> *will* mix and match qemu and modules, and get random crashes. AFAIK
> versioning is a good way to avoid that (you would get an error in
> dlopen(), and dlerror() would pinpoint problem).
> 
> No idea how to implement this though, except I expect there's no chance
> to do it halfway portably without libtool.

In libvirt we use ELF symbol versioning for all symbols that are
exported. Public symbols for applications to use get tagged with
something like   LIBVIRT_0.9.3 (according to the version the symbol
arrived in), and then private symbols exported solely for use by
loadable modules get tagged  LIBVIRT_PRIVATE_1.0.3. The version number
for the private tags is changed on every single release. This ensures
that loadable modules can only be loaded by a libvirt that was built
from the same version.

# eu-readelf -a /usr/lib64/libvirt.so | grep LIBVIRT | awk '{print $8}' | less
virPCIDeviceFileIterate@@LIBVIRT_PRIVATE_1.0.3
virDomainObjGetState@@LIBVIRT_PRIVATE_1.0.3
virXPathLongLong@@LIBVIRT_PRIVATE_1.0.3
virNetworkLookupByUUIDString@@LIBVIRT_0.2.0
sexpr_node_copy@@LIBVIRT_PRIVATE_1.0.3
virSecurityManagerPreFork@@LIBVIRT_PRIVATE_1.0.3
virDomainSaveStatus@@LIBVIRT_PRIVATE_1.0.3
virXPathULongLong@@LIBVIRT_PRIVATE_1.0.3
virDomainPinVcpu@@LIBVIRT_0.1.4
virCommandClearCaps@@LIBVIRT_PRIVATE_1.0.3


By having all the private symbols change their version tag on every
release, we make it a total PITA for anyone to provide closed source,
out of tree, third party modules. Which is nice a feature :-)

Symbol versioning like this isn't portable to Windows, but it works
on Solaris and Linux at least. I'm not sure about BSD support for
symbol versioning.

The other nice thing about symbol versioning (for RPM based distros)
is that RPM will auto-add dependancies for symbol versions. So if
you distribute loadable modules in a separate RPM from the main
binary RPM, the dependancies will ensure you always have matched
versions installed.

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