Re: [Qemu-devel] [PATCH v3 2/2] rbd: link and load librbd dynamically

[Stefan Hajnoczi <stefanha@redhat.com>]

On Wed, Apr 10, 2013 at 10:08:20AM -0500, Anthony Liguori wrote:
> Stefan Hajnoczi <stefanha@gmail.com> writes:
> 
> > On Wed, Apr 10, 2013 at 2:05 AM, Josh Durgin <josh.durgin@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