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: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH v3 2/2] rbd: link and load librbd dynamically
Date: Thu, 11 Apr 2013 10:04:37 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, Apr 10, 2013 at 11:19:03PM +0200, Paolo Bonzini wrote:
> Il 10/04/2013 17:08, Anthony Liguori ha scritto:
> > /* 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
> 
> Not even that is needed.  Modules can have constructor functions that
> use symbols in the main executable.
> 
> Basically, modules would be opened with G_MODULE_BIND_LOCAL and
> communicate with QEMU via constructor functions only (registering driver
> modules or QOM types).
> 
> It is really more of a build-system hacking project than anything else.

Great.  So it seems like we just need a function early in QEMU startup
that enumerates all shared libraries in QEMU_MODULE_PATH and opens them
with G_MODULE_BIND_LOCAL.

Perhaps in the future we'll load modules on-demand to avoid reduce
footprint, but for now we can just load all of them just like you get
when you build a QEMU binary with everything included.

Stefan



reply via email to

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