Re: [PATCH v2 17/18] modules: check arch and block load on mismatch

[Daniel P . Berrangé]

On Mon, Jun 14, 2021 at 03:44:53PM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> > > We can do both.  The file is generated and installed as part of the
> > > build/install process, and it can be simply used as-is even if some of
> > > the modules are missing.
> > > 
> > > It's also possible to update the modinfo.json file in postinstall /
> > > postuninstall by simply running qemu-modinfo, so only the modules
> > > actually installed are listed there.
> > 
> > I fail to see why that extra complication is needed at all.
> > 
> > Why don't we just build the modules for the targets we intend to build,
> > and install them as .so files in a target arch directory?
> 
> There is more meta-data we need for modules:  Which QOM types are
> implemented by which module (for on-demand loading), dependencies
> between modules and also which command line options (aka QemuOpts)
> are handled by which modules.
> 
> Possibly more in the future, maybe we'll support modules registering
> monitor commands dynamically some day (like usb-host implementing
> "info usbhost" or tcg implementing "info jit" + "info opcount") and
> we'd like store that information in the module database too.
> 
> If we have such a module database anyway it IMHO makes alot of sense
> to simply store the target arch there too instead of using something
> else.
> 
> > What problem is the json solving?
> 
> Well, the goal is to store meta-data about modules, in a way which:
> 
>   (a) Doesn't require manually maintained lists.  This is what we have
>       right now (arrays in utils/module.c).  Works ok-ish for a small
>       number of modules, but becomes increasingly problematic with the
>       growing number of modules.
>   (b) Doesn't require opening each individual module on each qemu run
>       to get the information.
> 
> I'm not particularly attached to using json for that, it is just that
> we already have infrastructure to parse/serialize structs from/to json
> because we need that for qapi anyway.

If we can generate json, we could generate .c code which has all the
data statically declared and just link it in to QEMU. If we don't need
ability to update the metadata post-build then it would be equivalent
functionally.  If we need to be able to update the metadata to precisely
matcch the set of installed modules though, then a separate json file
looks best.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|