From: Gerd Hoffmann <kraxel@redhat.com>
To: Claudio Fontana <cfontana@suse.de>
Cc: "Kevin Wolf" <kwolf@redhat.com>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Thomas Huth" <thuth@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
qemu-block@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>,
"Michael Roth" <michael.roth@amd.com>,
"Cornelia Huck" <cohuck@redhat.com>, "Peter Lieven" <pl@kamp.de>,
qemu-devel@nongnu.org, "Max Reitz" <mreitz@redhat.com>,
"Halil Pasic" <pasic@linux.ibm.com>,
"Christian Borntraeger" <borntraeger@de.ibm.com>,
qemu-s390x@nongnu.org,
"Ronnie Sahlberg" <ronniesahlberg@gmail.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Samuel Thibault" <samuel.thibault@ens-lyon.org>,
"David Hildenbrand" <david@redhat.com>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Eric Blake" <eblake@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>
Subject: Re: [PATCH v2 17/18] modules: check arch and block load on mismatch
Date: Mon, 14 Jun 2021 15:44:53 +0200 [thread overview]
Message-ID: <20210614134453.sgbezze6z223n4rk@sirius.home.kraxel.org> (raw)
In-Reply-To: <b3d35127-6ef3-2e2e-0341-a0076a499559@suse.de>
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
next prev parent reply other threads:[~2021-06-14 13:46 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
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 [this message]
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=20210614134453.sgbezze6z223n4rk@sirius.home.kraxel.org \
--to=kraxel@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cfontana@suse.de \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=eblake@redhat.com \
--cc=kwolf@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=michael.roth@amd.com \
--cc=mreitz@redhat.com \
--cc=mst@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=pl@kamp.de \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=ronniesahlberg@gmail.com \
--cc=samuel.thibault@ens-lyon.org \
--cc=thuth@redhat.com \
/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).