Peter Maydell <[email protected]> writes: > On Mon, 6 Feb 2023 at 14:14, Fabiano Rosas <[email protected]> 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. >> >> Even a experienced user that tweaks the build via .mak files is not >> required to know about what QEMU developers chose to use as fallbacks >> in the code. Moreover, the person/entity that builds the code might >> not be the same that runs it, which makes it even more confusing. >> >> We do have -nodefaults in the command line, but that doesn't include >> all types of fallbacks that might be set in the code. It also does not >> cover individual CONFIGs and their respective use as a fallback in the >> code. >> >> So my proposal here is actually simple: Let's make sure every fallback >> device creation *without* a validation check gets a hard dependency in >> Kconfig. A validation check being something like: >> >> if (has_defaults && object_get_class("foo") { >> create_foo(); >> } > > So we could do one of several things to resolve any particular > one of these: > (1) make the Kconfig force the device to be compiled in > (2) make QEMU silently fall back to "don't provide device" > rather than "provide this default device" if the > device isn't compiled in > (3) make QEMU emit an error message saying that the > command line implies that the machine should have > (default) device X but X support wasn't compiled in > > I don't strongly care which approach we take, but shouldn't > we be consistent about what we do? AFAICT your patch 1 > here takes approach (2) but the others take approach (1).
Good point. The one from patch 1 (isa-parallel) is a bit different since it is used in the -nodefaults logic, but I could probably use the (1) approach with it as well, let me give it a try.
