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