Peter Maydell <peter.mayd...@linaro.org> writes: > On Wed, 7 Aug 2024 at 12:10, Markus Armbruster <arm...@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?
