On 5/8/25 6:58 AM, Daniel P. Berrangé wrote:
Pierrick has proposed a series that introduces a concept of runtime
conditionals to the QAPI schema, in order to adapt the TARGET_*
conditionals currently used at build time:
https://lists.nongnu.org/archive/html/qemu-devel/2025-05/msg01699.html
For the sake of comparison & evaluation, this series illustrates the
alternative approach that we've discussed of entirely removing any
concept of TARGET_* conditionals.
With this the QAPI schema varies solely based on CONFIG_* conditionals,
and is thus invariant across different target emulators.
In this PoC I've taken the minimal effort approach to the problem.
The QAPI schema has removed the TARGET_* conditionals and in order to
make all the emulators then compile, the stubs/ directory is populated
with a bunch of files to provide dummy impls of the target specific QMP
commands.
This is sufficient to make the current QEMU binaries build successfully.
To make the "single binary" concept work, however, would require
additional followup work to eliminate the stubs.
Instead of having stubs we would need to de-couple the QMP command
impl from the machine internals. This would likely require greater
use of interfaces and/or virtual method dispatchers on the machine
class. This would enable the 'qmp_XXXXX' command impls to exist
once. Then they call out to virtual methods on the machine to provide
the real impl, and/or generate an error if the virtual method is not
implemented for the machine.
Thanks for posting it Daniel.
I think your approach is pretty neat, and yes, it's much simpler than
having any compile time or runtime conditional to deal with that.
When we talked about that on previous thread, I thought the idea was to
expose *all* the commands to *all* the targets, which I didn't really
understand, considering we have target specific commands by design.
I understand better where you wanted to go, by extracting concerned
commands in dedicated files.
The only downside I can see is that some commands have to be there, but
return an "error, not implemented" at runtime. Fine for me, but some
people may argue against it.
A concern I might have as well is about how we'll deal if we want to
hide some commands in the future, based on various criterias
(is_heterogenenous()?). The mantra "define all, and let the build system
hide things" mantra means you can only have a single definition existing
in the binary, by design. But maybe it's not even a real concern, and I
definitely prefer to see problems before fixing them, so it's definitely
not blocking this approach.
Overall, if I had to choose, I think I would pick your approach instead
of the "runtime conditional" route, it's just simpler and saner overall.
I would be happy to see you take ownership on that, as long as we can
deliver something in the next weeks. I can help on anything as well.
@Markus, @Michael, which approach would you prefer to be followed for QAPI?
Thanks,
Pierrick
