Re: [RFC PATCH-for-9.1? 2/2] hw/intc/arm_gic: Only provide query-gic-capabilities when GIC built-in

[Markus Armbruster <armbru@redhat.com>]

Peter Maydell <peter.maydell@linaro.org> writes:

> On Wed, 7 Aug 2024 at 12:10, Markus Armbruster <armbru@redhat.com> wrote:
>> Having to manually include a configuration header like CONFIG_DEVICES
>> wherever you use configuration symbols strikes me as unadvisable when
>> uses include checking for definedness, such as #ifdef: silent miscompile
>> when you forget to include.
>>
>> This is why Autoconf wants you to include config.h first in any .c: it
>> makes #ifdef & friends safe.
>>
>> qemu/osdep.h does include some configuration headers:
>>
>>     #include "config-host.h"
>>     #ifdef COMPILING_PER_TARGET
>>     #include CONFIG_TARGET
>>     #else
>>     #include "exec/poison.h"
>>     #endif
>>
>> Why not CONFIG_DEVICES?
>
> The stuff in CONFIG_DEVICES is target-specific, so wanting
> to include it should be rare (currently we include it in
> only about 25 files). Any file that includes it has to be
> a compile-per-target file, and generally we'd rather avoid that.

Since all the macros defined in CONFIG_DEVICES are poisoned by
exec/poison.h, which *is* included by qemu/osdep.h, target-independent
files never need to include CONFIG_DEVICES.  My question was strictly
about target-dependent files, i.e. exactly the ones that include
CONFIG_TARGET.

> Plus it's a bit odd to need to change code based on whether
> some other device was configured into the system,

I agree it's a bit odd for device code to check whether some other
device is also selected for the current target.

But is it odd for the QAPI schema to define a device-specific command
only when the device is selected?

>                                                   so I think
> that's something worth restricting to only files that effectively
> opt in to it.

Is accidental use of a macro from CONFIG_DEVICES a risk?  Is the risk
mitigated to some useful degree by having to include CONFIG_DEVICES?

I consider the combination of testing configuration symbols with #ifdef
and requiring a manual #include to actually get the symbols (and make
the #ifdef work) bad practice.

Options:

1. Approximate symbols from CONFIG_DEVICES with symbols from
   CONFIG_TARGET.  This is what we do now.

2. Use symbols from CONFIG_DEVICES.  Generated headers are no longer
   self-contained.  Strong dislike.

3. Define device-specific stuff unconditionally.  We get to fool around
   with stubs, binaries carry more useless code, and introspection
   becomes less useful.  Meh.

Thoughts?