Re: [PATCH 0/4] modules: add support for target-specific modules.

["José Ricardo Ziviani" <jose.ziviani@suse.com>]

[-- 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 --]