Paolo Bonzini <pbonz...@redhat.com> writes: > On 11/5/21 14:45, Markus Armbruster wrote: >> Moving these definitions to machine-target.json moves the generated C >> from qapi/qapi-*-machine.[ch] to qapi/qapi-*-machine-target.[ch], where >> CONFIG_ACPI_VMGENID is okay. It also makes qmp_query_vm_generation_id() >> target-dependent: it needs qapi/qapi-commands-machine-target.h. > > If I understand correctly, the problem that > qapi-commands-machine-target.h is target-dependent, because it uses > "#ifdef CONFIG_ACPI_VMGENID" around the prototype?
Around the prototype and struct GuidInfo. > On one hand, the "#ifdef" is unnecessary: the prototype does not > depend on anything target-specific. Removing it will avoid the > target-dependence. On the other hand, the "#ifdef" has a defensive > purpose, in that an unnecessary definition (such as the one currently > in the stub) will fail due to the implicit definition of > qmp_query_vm_generation_id(). Also, it immediately flags uses of qmp_query_vm_generation_id() and struct GuidInfo. Without it, the linker still catches most, but not all uses. >> Have you seen similar artificial target-dependence elsewhere? > > I can't think of a specific example, but it does ring some bells. I just ran into an instance that may be clearer. The "rocker" device is target-independent (hw/net/meson.build adds it to softmmu_ss), but linked only for selected targets (hw/net/Kconfig has depends on PCI && MSI_NONBROKEN). This makes our build machinery put CONFIG_ROCKER in $TARGET-softmmu-config-devices.h, and poison it in config-poison.h. Feels uncalled for.