Philippe Mathieu-Daudé <phi...@linaro.org> writes:
> On 23/2/23 15:27, Jonathan Cameron wrote:
>> On Thu, 23 Feb 2023 08:37:46 +0100
>> Markus Armbruster <arm...@redhat.com> wrote:
>>> Whenever you use a poisoned macro in a conditional, all the code
>>> generated for this .json file (we call it a "QAPI schema module")
>>> becomes target-dependent. The QAPI code generator itself is blissfully
>>> unaware of this.
>>>
>>> Since target-dependent code needs to be compiled differently, the build
>>> process needs to be know which modules are target-dependent. We do this
>>> in one of the stupidest ways that could possibly work: a module is
>>> target-dependent if its name ends with "-target". There are just two
>>> right now: qapi/machine-target.json and qapi/misc-target.json.
>>>
>>> The logic resides in qapi/meson.build. Look for
>>>
>>> if module.endswith('-target')
>>
>> Thanks for all the pointers.
>>
>>> Questions?
>>>
>> Is it sensible to make the cxl stuff all target dependent and do the
>> following?
>> I like that we can get rid of the stubs if we do this but I'm sure there are
>> disadvantages. Only alternative I can currently see is continue to have
>> stubs and not make the qmp commands conditional on them doing anything
>> useful.
>
> I still don't understand what is the target-dependent part of CXL.
>
> IIUC CXL depends on PCIe which isn't target dependent.
As far as I can tell, the target-dependent part of CXL is the macro
CONFIG_CXL :)
Consider a device model implemented in perfectly target-independent
code, to be linked only into some qemu-system-TARGET. How do we do
that?
We put a 'config FOO' section in the appropriate Kconfig, and select it
from the target's Kconfig for the targets that want it. We add device
model sources to Meson source set softmmu_ss when CONFIG_FOO.
This puts CONFIG_FOO=y into the TARGET-softmmu-config-devices.mak, and
#define CONFIG_FOO 1 into TARGET-softmmu-config-devices.h. It also puts
#pragma GCC poison CONFIG_FOO into config-poison.h.
Note the two CONFIG_FOO have subtly different meaning:
* The make variable means "there is an enabled target that has FOO
enabled". It gets propagated to Meson.
* The C macro means "the current target has FOO enabled". It therefore
must not be used in target-independent code. That's why we poison it
in config-poison.h.
Note that the device model code has no use for C macro CONFIG_FOO. It
remains target-independent as it should.
Now consider how to have the QAPI schema provide something for FOO.
If we make it a QAPI schema module of its own, we can arrange for it to
be linked only into the qemu-system-TARGET that have the device model,
just like the device model code. We haven't tried this for individual
devices, only for whole subsystems like PCI.
If we don't make it a module of its own, we have two choices:
* We use 'if': 'CONFIG_FOO'. This is actually the C macro. The module
becomes target-dependent. We compile the code generated for the
module separately for each target.
* We make it unconditional. The module can remain target-independent.
The code generated for FOO's QAPI schema is linked unconditionally,
even when the target doesn't need it. Any references to handwritten
FOO code need to be satisfied with stubs.
I dislike both. Existing usage seems to prefer "unconditional schema".
Sticking to that is okay.
