Re: [PATCH 1/2] meson: introduce modules_arch

[Gerd Hoffmann]

On Tue, Sep 21, 2021 at 10:35:04AM -0300, Jose R. Ziviani wrote:
> Hello!!
> 
> On Tue, Sep 21, 2021 at 07:25:42AM +0200, Gerd Hoffmann wrote:
> >   Hi,
> > 
> > > But, in anyway, I'll still need to store the target architecture that
> > > can use such core module, like I did here in this patch. Otherwise,
> > > if I compile different targets at the same time, I'll end up with the
> > > same problem of targets trying to load wrong modules.
> > 
> > That all works just fine today.  If you have target-specific modules
> > (i.e. source files added to specific_ss instead of softmmu_ss when
> > compiling into core qemu) you only need to add those to the
> > target_modules[] (instead of modules[]) and you are set.
> > 
> > In-tree example: qtest accelerator.
> 
> Exactly, but what it doesn't seem to work (or I'm not understanding it
> well) is: how the target will know whether it can or cannot load a
> module.

Well, for target-specific modules that is easy:  You get one module per
target, and each target loads the matching module only.

> For example, suppose I build target-list=s390x-softmmu,x86_64-softmmu.
> Both targets will be linked to the same modinfo.c object, which will
> have a 'hw-display-virtio-gpu-pci' entry (it wouldn't if I build only
> s390x-softmmu). When I execute ./qemu-system-s390x, it will try to
> load hw-display-virtio-gpu-pci and will throw the errors I mentioned
> earlier.

Yes.  That isn't a target-specific module.  It will load into any target
which has pci support.  You can add aarch64-softmmu to the list above,
and then notice that both aarch64-softmmu and x86_64-softmmu can load
the very same hw-display-virtio-gpu-pci module.

> If, for example, I add that module_need(PCI_BUS), we will continue
> not knowing whether the target in execution has the required bus
> (without injecting dependencies in module.c).

Yes, you'll need a 'module_provides(PCI_BUS)' somewhere in the pci
initialization code (likewise for the other features), so the module
code knows which features are present and can check that against the
list of 'module_needs(...)' of the module.

Trying to have kconfig export that information instead of adding
"module_needs()" + "module_provides()" annotations to the source
should work too.  Not sure which is easier.

With the kconfig approach you have all information needed at compile
time, so you can do compile-time filtering and build per-target modinfo
lists (paolo's idea) instead of using a single list with
runtime-filtering (which is what we have now).

take care,
  Gerd