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.
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).
So we would need both if and runtime_if.
With this QAPI schemas would have remained fully self-contained.
Fortunately, this is merely a matter of filling a gap we left, not a
matter of replacing a fundamentally flawed design.
Anyway, this is a long way of saying that having 'runtime_if'
conditions directly referencing the names of internal C
functions makes me even more uncomfortable than I already am
with the 'if' conditions.
The meaning of the QAPI schema now varies based on both the build
system, and an arbitrary amount of C, and is thus (conceptually)
even more opaque, even if you could infer some meaning from the
'target_s390x()' function name you've used. I think this is a very
undesirable characteristic for what is our public API definition.
I don't see much of a difference, to be honest.
Both kinds of conditionals have the exact same argument structure:> expression
tree where the leaves are identifiers.
The meaning of these identifiers is not documented in the QAPI schema
now, and barely documented in the code.
I agree on that, and I'm not sure that introducing another level of
symbolic names (target-s390x vs target_s390x()) to match the same C
function name really adds any value to the QAPI definition.
As mentioned before, it's easy to guarantee that the function is named
the same in any language, and ban any use of C complex expression
(through code review), so the argument about generating bindings in
other languages does not really matter IMHO.
This defect could be remedied the exact same way whether the identifiers
are preprocessor macros or function names.
I actually find another argument of yours (not repeated above) more
compelling: that certain aspects of the external interface should not
vary at runtime.
