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.
take care,
Gerd
