QEMU-Devel Archive mirror
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [PATCH v2 03/18] modules: add qemu-modinfo utility
Date: Mon, 14 Jun 2021 17:01:59 +0200	[thread overview]
Message-ID: <20210614150159.6ilpce4dqxi7rju4@sirius.home.kraxel.org> (raw)
In-Reply-To: <1636b96e-9073-b145-3fcc-3370fa2d7506@redhat.com>

  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



  parent reply	other threads:[~2021-06-14 15:03 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-10  5:57 [PATCH v2 00/18] modules: add metadata database Gerd Hoffmann
2021-06-10  5:57 ` [PATCH v2 01/18] modules: add metadata macros, add qxl module annotations Gerd Hoffmann
2021-06-10  5:57 ` [PATCH v2 02/18] qapi: add ModuleInfo schema Gerd Hoffmann
2021-06-14  7:48   ` Markus Armbruster
2021-06-14 15:21     ` Gerd Hoffmann
2021-06-14 16:53       ` Markus Armbruster
2021-06-10  5:57 ` [PATCH v2 03/18] modules: add qemu-modinfo utility Gerd Hoffmann
2021-06-10 13:04   ` Gerd Hoffmann
2021-06-10 13:13     ` Daniel P. Berrangé
2021-06-14  8:34       ` Paolo Bonzini
2021-06-14 14:36         ` Paolo Bonzini
2021-06-15  4:49           ` Gerd Hoffmann
2021-06-15  7:56             ` Gerd Hoffmann
2021-06-15 13:07               ` Gerd Hoffmann
2021-06-15 13:35                 ` Paolo Bonzini
2021-06-16  9:16                   ` Gerd Hoffmann
2021-06-16 10:53                     ` Paolo Bonzini
2021-06-14 15:01         ` Gerd Hoffmann [this message]
2021-06-14 15:08           ` Daniel P. Berrangé
2021-06-15  4:54             ` Gerd Hoffmann
2021-06-15  9:27               ` Daniel P. Berrangé
2021-06-10  5:57 ` [PATCH v2 04/18] modules: add virtio-gpu module annotations Gerd Hoffmann
2021-06-10  5:57 ` [PATCH v2 05/18] modules: add chardev " Gerd Hoffmann
2021-06-10  5:57 ` [PATCH v2 06/18] modules: add audio " Gerd Hoffmann
2021-06-10  5:57 ` [PATCH v2 07/18] modules: add usb-redir " Gerd Hoffmann
2021-06-10  5:57 ` [PATCH v2 08/18] modules: add ccid " Gerd Hoffmann
2021-06-10  5:57 ` [PATCH v2 09/18] modules: add ui " Gerd Hoffmann
2021-06-10  5:57 ` [PATCH v2 10/18] modules: add s390x " Gerd Hoffmann
2021-06-10  5:57 ` [PATCH v2 11/18] modules: add block " Gerd Hoffmann
2021-06-10  5:57 ` [PATCH v2 12/18] modules: add module_load_path_init helper Gerd Hoffmann
2021-06-10  5:57 ` [PATCH v2 13/18] modules: load modinfo.json Gerd Hoffmann
2021-06-10  5:57 ` [PATCH v2 14/18] modules: use modinfo for dependencies Gerd Hoffmann
2021-06-10  5:57 ` [PATCH v2 15/18] modules: use modinfo for qom load Gerd Hoffmann
2021-06-10  5:57 ` [PATCH v2 16/18] modules: use modinfo for qemu opts load Gerd Hoffmann
2021-06-10  5:57 ` [PATCH v2 17/18] modules: check arch and block load on mismatch Gerd Hoffmann
2021-06-10 12:35   ` Daniel P. Berrangé
2021-06-10 12:57     ` Gerd Hoffmann
2021-06-10 13:06       ` Daniel P. Berrangé
2021-06-10 14:03         ` Gerd Hoffmann
2021-06-14 11:23           ` Claudio Fontana
2021-06-14 13:44             ` Gerd Hoffmann
2021-06-14 13:52               ` Daniel P. Berrangé
2021-06-14 14:10                 ` Gerd Hoffmann
2021-06-14 11:19     ` Claudio Fontana
2021-06-10  5:57 ` [PATCH v2 18/18] [fixup] module_load_modinfo Gerd Hoffmann
2021-06-10  6:24   ` Gerd Hoffmann
2021-06-10  8:32 ` [PATCH v2 00/18] modules: add metadata database Claudio Fontana
2021-06-10  9:54   ` Gerd Hoffmann
2021-06-14 11:31     ` Claudio Fontana
2021-06-14 14:07       ` Gerd Hoffmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210614150159.6ilpce4dqxi7rju4@sirius.home.kraxel.org \
    --to=kraxel@redhat.com \
    --cc=berrange@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).