Re: [PATCH 09/13] qapi: transform target specific 'if' in runtime checks

[Markus Armbruster <armbru@redhat.com>]

Pierrick Bouvier <pierrick.bouvier@linaro.org> writes:

> On 5/13/25 12:08 AM, Markus Armbruster wrote:
>> Pierrick Bouvier <pierrick.bouvier@linaro.org> writes:
>> 
>>> On 5/9/25 11:57 PM, Markus Armbruster wrote:
>>>>> The build system would need generate an input document for the
>>>>> QAPI visitor that defines whether each constant is set to true
>>>>> or false, based on suitable CONFIG/TARGET conditions from meson.
>>>>
>>>> I think the conditions that are evaluated at build time in handwritten C
>>>> code (with #if) should also be evaluated at build time in generated C
>>>> code.
>>>>
>>>> Certain conditions are evaluated at build time in target-specific code,
>>>> and at runtime in target-independent code.  Again, I think handwritten
>>>> and generated code should work the same way.
>>>>
>>>> Thus, to eliminate target-specific QAPI-generated code, we either
>>>> evaluate them at runtime, or simply eliminate them.  Elsewhere, we've
>>>> come to the conclusion (I think) that the latter should do at least for
>>>> now, likely forever, so we should try that first.
>>>>
>>>
>>> I'm not sure if you mean you'd prefer to eradicate #if completely.
>> 
>> I do not!
>> 
>>> We have to keep in mind that some config host #if have to stay there, or
>>> they expose things that the rest of QEMU code is not supposed to see
>>> (hidden under those same CONFIG_ ifdef also).
>> 
>> Letting people configure their QEMU build is useful and must stay.
>> 
>> We provide this via conditional compilation, of complete source files
>> (done in meson), as well as within source files (#if in C and 'if' in
>> QAPI).
>> 
>>> So we would need both if and runtime_if.
>> 
>> I don't understand the need for runtime_if.  Can you give an example?
>>
>
> That is the point of this whole series, which explores introducing a 
> 'runtime' if in the schema, to keep it as it is today, while removing 
> target specific compile time defines.

Ah, I lost the wider context, sorry!

We identified three ways to deal with target-specific conditionals in a
single binary, and 'runtime_if' is one of them:

(1) Drop target-specific conditionals.

(2) Replace them by run-time checks.

(3) Have target-specific QAPI-generated code for multiple targets
    coexist in the single binary.

Both (2) and (3) keep the QAPI schema work as it does now.  None of us
likes (3) due to bloat and complexity.

The other two look both workable to me.  (2) keeps the QAPI schema work
exactly as it does now.  (1) is simpler, but the external interface
changes somewhat.  Its users seem to be okay with it.

So let's go with (1).

> It is another approach that one Daniel followed on his series.
>
> I invite you to give a quick read to this series, especially the related 
> commit introducing 'runtime_if' 
> (20250507231442.879619-2-pierrick.bouvier@linaro.org).

I can't afford a thorough review now, but I'll have a look, and I will
hold onto your series just in case.

> As well, I would appreciate if you could state clearly where we are 
> going with all this (or at least, where you *don't* want this to go), so 
> we can avoid spending time in the wrong direction.

The discussion was spread over multiple threads, which makes it hard to
follow.  I hope the conclusion is clear now.  If not, please ask for
further clarification.

> I am ok to pursue Daniel's approach, or continue the approach in the 
> current series, no strong opinion in my side, I am just trying to move 
> QAPI generated code out of the way for the single binary goal.

Understood!