Re: [Qemu-devel] [PATCH v10 5/8] module: implement module loading

[Fam Zheng <famz@redhat.com>]

On Mon, 09/16 14:36, Gerd Hoffmann wrote:
> On Mo, 2013-09-16 at 12:05 +0100, Daniel P. Berrange wrote:
> > On Mon, Sep 16, 2013 at 02:50:24PM +0800, Fam Zheng wrote:
> > > Added three types of modules:
> > > 
> > >     typedef enum {
> > >         MODULE_LOAD_BLOCK = 0,
> > >         MODULE_LOAD_UI,
> > >         MODULE_LOAD_NET,
> > >         MODULE_LOAD_MAX,
> > >     } module_load_type;
> > > 
> > > and their loading function:
> > > 
> > >     void module_load(module_load_type).
> > > 
> > > which loads whitelisted ".so" files of the given type under ${MODDIR}.
> > > 
> > > Modules of each type should be loaded in respective subsystem
> > > initialization code.
> > 
> > Based on Paolo's note that the SPICE .so module could likely
> > end up containing functionality that is spread across several
> > different sub-systems, this approach of loading per-type
> > seems even more flawed.
> 
> spice would need different types indeed (and the list above looks
> incomplete).
> 
> > I think I'd just have one flat list
> > of modules to load and ditch these  MODULE_LOAD_XXXX enums.
> 
> Question is how to deal with qemu vs. qemu-img then.  qemu needs
> everything and qemu-img needs the block drivers only (and loading
> something else probably doesn't work due to unresolved symbols).
> 

With lazy symbol binding (G_MODULE_BIND_LAZY), we can just load all the
modules, and wait for subsystem to call module_call_init(MODULE_INIT_*), where
the symbols are resolved. As qemu-img.c doesn't init ui, net, it's not a
problem to load them ahead.

Fam