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