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

[Anthony Liguori <anthony@codemonkey.ws>]

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.

Regards,

Anthony Liguori

>
> Stefan