qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Sage Weil
Subject: Re: [Qemu-devel] [PATCH v3 2/2] rbd: link and load librbd dynamically
Date: Fri, 21 Jun 2013 11:42:34 -0700 (PDT)
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)

Hi Anthony, Stefan, Paolo,

[Resurrecting an old thread, here!]

On Wed, 10 Apr 2013 Anthony Liguori wrote:
> Stefan Hajnoczi <address@hidden> writes:
> > 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

Has any progress been made toward a generic dynamic linking solution for 
block drivers?  It is a conceptually simple change, but non-trivial for 
anyone unfamiliar with the build system.

In the mean time, the inability to dynamically link librbd is continuing 
to cause significant pain for distro users.  Would you consider merging 
the rbd-specific linking as an interim solution until something is 
generically available to qemu?

sage



reply via email to

[Prev in Thread] Current Thread [Next in Thread]