On 8/2/23 20:26, Fabiano Rosas wrote:
We currently have a situation where disabling a Kconfig might result
in a runtime error when QEMU selects the corresponding device as a
default value for an option. But first a disambiguation:
Kconfig default::
a device "Foo" for which there's "config FOO default y" or "config X
imply FOO" in Kconfig.
QEMU hardcoded default::
a fallback; a device "Foo" that is chosen in case no corresponding
option is given in the command line.
The issue I'm trying to solve is that there is no link between the two
"defaults" above, which means that when the user at build time
de-selects a Kconfig default, either via configs/devices/*/*.mak or
--without-default-devices, the subsequent invocation at runtime might
continue to try to create the missing device due to QEMU defaults.
This will keep bitrotting if we don't cover such configs in our CI.
Why do you want to get this fixed BTW? I'm not sure there is a big
interest (as in "almost no users").
I tried to do that few years ago [*] and Thomas said:
"in our CI, we should test what users really need,
and not each and every distantly possible combination."