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