Re: Can we unpoison CONFIG_FOO macros?

[Peter Maydell]

On Tue, 7 Feb 2023 at 15:41, Markus Armbruster <armbru@redhat.com> wrote:
> We have a boatload of CONFIG_FOO macros that may only be used in
> target-dependent code.  We use generated config-poison.h to enforce.
>
> This is a bit annoying in the QAPI schema.  Let me demonstrate with an
> example: QMP commands query-rocker, query-rocker-ports, and so forth.
> These commands are useful only with "rocker" devices.  They are
> compile-time optional.  hw/net/Kconfig:
>
>     config ROCKER
>         bool
>         default y if PCI_DEVICES
>         depends on PCI && MSI_NONBROKEN
>
> The rocker device and QMP code is actually target-independent:
> hw/net/meson.build puts it into softmmu_ss.
>
> Disabling the "rocker" device type ideally disables the rocker QMP
> commands, too.  Should be easy enough: 'if': 'CONFIG_FOO' in the QAPI
> schema.
>
> Except that makes the entire code QAPI generates for rocker.json
> device-dependent: it now contains #if defined(CONFIG_ROCKER), and
> CONFIG_ROCKER is poisoned.  The rocker code implementing monitor
> commands also becomes device-dependent, because it includes generated
> headers.  We compile all that per target for no sane reason at all.
> That's why we don't actually disable the commands.
>
> Not disabling them creates another problem: we have the commands always,
> but their implementation depends on CONFIG_ROCKER.  So we provide stubs
> that always fail for use when CONFIG_ROCKER is off.  Drawbacks: we
> generate, compile and link useless code, and QAPI/QMP introspection is
> less useful than it could be.

If you want the introspection to be useful, then you need to
make the appearance of the commands depend on what machine
type and devices are created on the command line. There are
lots of machine types where the rocker commands are irrelevant
because they don't apply to that machine even though it happens
that PCI_DEVICES got built into that QEMU executable.

I think the underlying question is "what does it mean to be
only building in a QMP command when a Kconfig value is set?".
It doesn't mean "this command only appears when it's useful",
so anybody introspecting with QMP has to handle the "command
exists but doesn't do anything helpful" case anyway. My guess
is that the check you're trying to do at compile time ought
to be done at runtime somehow instead (which is a general
theme for 'single system emulation executable' work).

thanks
-- PMM