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
