Re: [PATCH v2 03/18] modules: add qemu-modinfo utility

[Gerd Hoffmann]

  Hi,

> > softmmu_mods and block_mods are both lists already, so this sets a
> > nested list and I wonder if it confuses meson  ? eg do you need
> > 
> >   input: softmmu_mods + block_mods
> 
> No, that should be fine.  Perhaps it's because the inputs are not part of
> the command?  You can check what the build.ninja rule for modinfo.json looks
> like.
> 
> Also:
> 
> - it would be better to support both directories and file names, so that
> stale modules are not included in modinfo.json

When turning qemu-modinfo into a pure build-utility (see below) there is
no reason to not explicitly list all module files on the command line.

> - modinfo.json needs to be disabled on non-ELF platforms (x86, Windows).

On windows modules are not supported.
Do we have any other non-ELF platforms?

> One alternative is to use libbfd instead of including an ELF parser.
> 
> - If modinfo.json has to be installed, you need to build modinfo for the
> build machine in order to support cross compiling.  That however would
> require a cross libbfd, which is a pain.  Do you really need to install it?

Do you mean installing modinfo.json or installing qemu-modinfo?  For the
latter I can see that not installing it removes some cross-compiling
headaches.  And, yes, we can turn this into a pure build utility
generating a static database (be it json or -- as suggested by Daniel --
a C source file with the data structures).

> Can the functionality instead be included in the main QEMU binary with a
> query-modules command or something like that.

Well, the meta-data database is meant for qemu itself, not external
users.  I was just using json because the infrastructure to serialize +
parse json exists.  Not sure a "query-modinfo" command makes sense.
Would be trivial to implement though if libvirt finds this useful
(assuming we stick to json).

I was toying with a completely different idea:  Have a "qemu
-generate-modinfo".  That would basically try to load each module, while
doing so record the type_register() (+ other register) calls the module
is doing, when done write out the database with the registrations done
by each module.

Problem with that approach is that it doesn't work for module
dependencies ...

Comments on the idea?  Suggestions for the module dependency problem?
Could maybe libbfd be used to find module (symbol) dependencies
automatically without writing a full dynamic linker?

take care,
  Gerd