From: "José Ricardo Ziviani" <jose.ziviani@suse.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Christian Schoenebeck" <qemu_oss@crudebyte.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"Greg Kurz" <groug@kaod.org>,
"Claudio Fontana" <cfontana@suse.de>,
"Philippe Mathieu-Daudé" <f4bug@amsat.org>
Subject: Re: [PATCH 0/4] modules: add support for target-specific modules.
Date: Tue, 15 Jun 2021 15:48:57 +0000 [thread overview]
Message-ID: <2963309.4TrVdrBa0x@pizza> (raw)
In-Reply-To: <20210615050930.bmgup2axfr7sqvoa@sirius.home.kraxel.org>
[-- Attachment #1: Type: text/plain, Size: 2501 bytes --]
On terça-feira, 15 de junho de 2021 02:09:30 -03 Gerd Hoffmann wrote:
> On Mon, Jun 14, 2021 at 10:19:27PM +0000, José Ricardo Ziviani wrote:
> > Hello Gerd,
> >
> > On sexta-feira, 11 de junho de 2021 10:03:21 -03 Gerd Hoffmann wrote:
> > > Hi,
> > >
> > > > Are there any pending patches to handle the remaining tcg dependencies
> > > > in qemu? When trying to build tcg modular (more than only
> > > > tcg-accel-ops*) I get lots of unresolved symbols to tcg bits which are
> > > > referenced directly (in cpu.c, gdbstub.c, monitor, ...).
> > > >
> > > > The CONFIG_TCG=n case is handled either with stubs or with #ifdef
> > > > CONFIG_TCG, which doesn't fly for modular tcg ...
> > >
> > > So, enough for today, to be continued next week.
> > > Work branch pushed to
> > >
> > > https://git.kraxel.org/cgit/qemu/log/?h=sirius/modinfo-playground
> > >
> > > Topmost patch doesn't compile but shows the build changes.
> >
> > I cloned your 'sirius/modinfo-playground-good' and started playing with
> > the
> > command line options to build these modules. I would like to suggest to
> > change the current "--enable-X" with "--X=[enabled,disabled,module]",
> > that seems to
> > make more sense for these modules. For instance:
> Hmm, what would be the use case? Right now qemu has the all-or-nothing
> approach for modules, i.e. if modules are enabled everything we can
> build as module will be built as module, and I havn't seen any drawbacks
> so far. So, why would one compile parts of qemu as module and other
> parts not?
From my point of view, as a QEMU package maintainer, the all-or-nothing module
approach is great - specially for accelerators - because we can create a set
of officially supported packages and another set of optional modules, that
users may get them if they want to.
However, please correct me if I'm wrong, I understand that an accelerator as a
module will add an overhead that some user won't be willing to pay. So, give
them the option to have built-in accelerators seems a good idea. Of course, I
haven't measured anything yet so my opinion about it may be misleading.
>
> Also: when changing this I think it would be good to maintain backward
> compatibility and use something like this:
>
> --enable-tcg=builtin
> --enable-tcg=module
> --enable-tcg (use default, probably "module" when modules
> are enabled and "builtin" otherwise)
> --disable-tcg
>
This is a better idea.
Thank you!!
> take care,
> Gerd
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2021-06-15 16:19 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-10 10:15 [PATCH 0/4] modules: add support for target-specific modules Gerd Hoffmann
2021-06-10 10:15 ` [PATCH 1/4] modules: factor out arch check Gerd Hoffmann
2021-06-10 10:15 ` [PATCH 2/4] modules: check arch on qom lookup Gerd Hoffmann
2021-06-10 10:15 ` [PATCH 3/4] modules: target-specific module build infrastructure Gerd Hoffmann
2021-06-10 10:15 ` [PATCH 4/4] modules: build virtio-9p modular Gerd Hoffmann
2021-06-10 10:34 ` [PATCH 0/4] modules: add support for target-specific modules Claudio Fontana
2021-06-10 12:23 ` Gerd Hoffmann
2021-06-10 13:10 ` Gerd Hoffmann
2021-06-10 13:12 ` Claudio Fontana
2021-06-11 7:35 ` Paolo Bonzini
2021-06-11 8:29 ` Gerd Hoffmann
2021-06-11 13:03 ` Gerd Hoffmann
2021-06-11 13:17 ` Claudio Fontana
2021-06-14 22:19 ` José Ricardo Ziviani
2021-06-15 5:09 ` Gerd Hoffmann
2021-06-15 15:48 ` José Ricardo Ziviani [this message]
2021-06-16 9:28 ` Gerd Hoffmann
2021-06-16 12:23 ` Claudio Fontana
2021-06-17 5:37 ` Gerd Hoffmann
2021-06-17 7:48 ` Claudio Fontana
2021-06-17 9:48 ` Gerd Hoffmann
2021-06-17 10:07 ` Claudio Fontana
2021-06-11 17:14 ` Paolo Bonzini
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=2963309.4TrVdrBa0x@pizza \
--to=jose.ziviani@suse.com \
--cc=cfontana@suse.de \
--cc=f4bug@amsat.org \
--cc=groug@kaod.org \
--cc=kraxel@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu_oss@crudebyte.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.