| Message ID | 20230206140809.26028-1-farosas@suse.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | Kconfig vs. default devices | expand |
On Mon, 6 Feb 2023 at 14:14, Fabiano Rosas <farosas@suse.de> 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). thanks -- PMM
Peter Maydell <peter.maydell@linaro.org> writes: > On Mon, 6 Feb 2023 at 14:14, Fabiano Rosas <farosas@suse.de> 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.
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(); } Fabiano Rosas (10): vl.c: Do not add isa-parallel if it's not present hw/i386: Select E1000E for q35 hw/i386: Select VGA_PCI in Kconfig hw/i386: Select E1000_PCI for i440fx hw/arm: Select VIRTIO_NET for virt machine hw/arm: Select VIRTIO_BLK for virt machine hw/arm: Select XLNX_USB_SUBSYS for xlnx-zcu102 machine hw/arm: Select GICV3_TCG for sbsa-ref machine hw/arm: Select e1000e for sbsa-ref machine hw/arm: Select VGA_PCI for sbsa-ref machine hw/arm/Kconfig | 7 +++++++ hw/i386/Kconfig | 6 +++--- softmmu/vl.c | 3 ++- 3 files changed, 12 insertions(+), 4 deletions(-)