Re: [RFC PATCH 0/3] single-binary: make QAPI generated files common

Pierrick Bouvier <pierrick.bouvier(a)linaro.org&gt; writes: Define "notice a difference" :) More on that below. Makes sense to me. To be precise: conditionals that use macros restricted to target-specific code, i.e. the ones poisoned by exec/poison.h. Let's call them target-specific QAPI conditionals. The QAPI generator is blissfully unaware of all this. The build system treats QAPI modules qapi/*-target.json as target-specific. The .c files generated for them are compiled per target. See qapi/meson.build. Only such target-specific modules can can use target-specific QAPI conditionals. Use in target-independent modules will generate C that won't compile. Poisoned macros used in qapi/*-target.json: CONFIG_KVM TARGET_ARM TARGET_I386 TARGET_LOONGARCH64 TARGET_MIPS TARGET_PPC TARGET_RISCV TARGET_S390X You're trying to eliminate target-specific QAPI conditionals. Correct? This affects QAPI/QMP introspection, i.e. the value of query-qmp-schema. Management applications can no longer use introspection to find out whether target-specific things are available. For instance, query-cpu-definitions is implemented for targets arm, i386, loongarch, mips, ppc, riscv, and s390x. It initially was for fewer targets, and more targets followed one by one. Still more may follow in the future. Right now, management applications can use introspection to find out whether it is available. That stops working when you make it available for all targets, stubbed out for the ones that don't (yet) implement it. Management applications may have to be adjusted for this. This is not an attempt to shoot down your approach. I'm merely demonstrating limitations of your promise "if anyone notices a difference, it will be a bug." Now, we could get really fancy and try to keep introspection the same by applying conditionals dynamically somehow. I.e. have the single binary return different introspection values depending on the actual guest's target. This requires fixing the target before introspection. Unless this is somehow completely transparent (wrapper scripts, or awful hacks based on the binary's filename, perhaps), management applications may have to be adjusted to actually do that. Applies not just to introspection. Consider query-cpu-definitions again. It currently returns CPU definitions for *the* target. What would a single binary's query-cpu-definitions return? The CPU definitions for *all* its targets? Management applications then receive CPUs that won't work, which may upset them. To avoid noticable difference, we again have to fix the target before we look. Of course, "fixing the target" stops making sense once we move to heterogeneous machines with multiple targets. For better or worse, generated documentation always contains everything. An argument could be made for stripping out documentation for the stuff that isn't included in this build. I'm not sure what you mean by "to limit qmp commands visible". QAPI/QMP introspection has all commands and events, and all types reachable from them. query-qmp-schema returns an array, where each array element describes one command, event, or type. When a command, event, or type is conditional in the schema, the element is wrapped in the #if generated for the condition. Yes, if we can find acceptable solutions for the problems that come with it. Maybe. I'm throwing in devel(a)lists.libvirt.org.