On 5/7/25 4:32 AM, Daniel P. Berrangé wrote:
On Wed, May 07, 2025 at 09:55:13AM +0200, Markus Armbruster wrote:
Pierrick Bouvier <pierrick.bouv...@linaro.org> writes:
[...]
I don't think we should think too much ahead for languages other than C,
for one, two, and even three reasons :)
I agree that thinking ahead too much is a bad habit. So is thinking
ahead too little :)
- First, it's already broken because we rely on ifdef that won't be
there in Rust or Go.
I don't think it's broken. QAPI 'if' translates straightforwardly to C
#if, but that doesn't mean it cannot be translated to conditional
compilation / metaprogramming in other languages.
In fact, the value of 'if' used to be C constant expressions suitable
for use with #if, and we changed it to its current form specifically to
enable Rust work, in merge commit c83fcfaf8a5. Marc-André's was trying
to develop Rust bindings back then, and if I remember correctly this
change was enough to let him implement 'if' with Rust.
The usefulness of the conditions to non-C languages may well
vary depended on intended use case.
If I'm writing a mgmt app that can talk to QEMU, and I want
to be able to talk to both x86 and s390 system emulators,
I am unlikely to want the language bindings to omit features
based on TARGET_xxx conditions. I won't want a separate API
for each QEMU arch target, I'll want one API for all arches.
Expanding this further, if I'm writing a mgmt app to talk
to QEMU 9.2.0, I am also unlikely to want the language
bindings to omit features based on CONFIG_xxxx conditions,
because I likely want to talk to a QEMU 9.2.0 built by any
OS distro, each of which may have chosen a different set
of --enable flags for configure, and thus having different
CONFIG_xxx conditions.
TL;DR: in terms of code generation, the prime use case for
conditionally generated code is for QEMU's own internal usage.
For QMP bindings generated for 3rd party app usage, the use
of conditions in generation feels like a niche requirment at
best.
IMHO the code for any public facing API derived from QMP
schema should be invariant for any given QEMU release.
I respect both opinions: expose the same interface, or relax what we
expose, and adapt the consumers.
A long term solution could be the latter, but we need to be able to
remove target dependencies in QAPI without spending N months on this
topic, so I favor the former, keeping things stable.
It will not prevent anyone to do further cleanups, nor make it more
difficult anyway.
With regards,
Daniel
Regards,
Pierrick
