On Wed, Apr 10, 2013 at 10:08:20AM -0500, Anthony Liguori wrote: > Stefan Hajnoczi <stefa...@gmail.com> writes: > > > On Wed, Apr 10, 2013 at 2:05 AM, Josh Durgin <josh.dur...@inktank.com> > > wrote: > > NACK > > > > I think we're solving the problem at the wrong level. Writing our own > > dynamic linker and adding boilerplate to juggle function pointers > > every time we use a library dependency is ugly. > > > > There are two related problems here: > > > > 1. Packagers do not want to enable niche dependencies since users will > > complain that the package is bloated and pulls in too much stuff. > > > > 2. QEMU linked against a newer library version fails to run on hosts > > that have an older library. > > > > Problem #1 has several solutions: > > > > 1. Let packagers take care of it. For example, vim is often shipped > > in several packages that have various amounts of dependencies > > (vim-tiny, vim-gtk, etc). Packagers create the specialized packages > > for specific groups of users to meet their demands without dragging in > > too many dependencies. > > > > 2. Make QEMU modular - host devices should be shared libraries that > > are loaded at runtime. There should be no stable API so that > > development stays flexible and we discourage binary-only modules. > > This lets packagers easily ship a qemu-rbd package, for example, that > > drops in a .so file that QEMU can load at runtime. > > > > Problem #2 is already solved: > > > > The dynamic linker will refuse to load the program if there are > > missing symbols. It's not possible to mix and match binaries across > > environments while downgrading their library dependencies. With > > effort, this could be doable but it's not an interesting use case that > > many users care about - they get their binaries from a distro or build > > them from source with correct dependencies. > > > > Maybe it's time to move block drivers and other components into > > modules? > > This is really a build system issue more than anything else. There are > no internal API changes needed. > > All that's needed is to something like (in module.h): > > /* This should not be used directly. Use block_init etc. instead. */ > #ifdef CONFIG_MODULE > #define module_init(function, type) \ > const gchar *g_module_check_init(GModule *module) \ > { \ > register_module_init(function, type); \ > return NULL; \ > } > #else > #define module_init(function, type) \ > static void __attribute__((constructor)) do_qemu_init_ ## function(void) { \ > register_module_init(function, type); \ > } > #endif > > We then also need a way to load modules prior to calling init using the > GModule interfaces. Easiest thing to do is just load all .so's in a > single directory (/usr/lib/qemu/modules/*.so?) prior to calling any > module init functions. > > What we need from the build system is the ability to build things either > builtin or as modules. Paolo has a GSoC proposal to integrate kconfig. > This would be a great approach to solving this problem. > > Doing it this way would let us build not only block drivers but also > devices as modules. This would let us make QXL a module making it > easier for distros to not have a hard dependence on libspice for the > QEMU package.
I'd love to do this for the net subsystem as well so distros can provide the qemu-net-vde package without requiring a VDE dependency from the core QEMU package. Stefan