qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH v2 00/10] Kconfig vs. default devices


From: Fabiano Rosas
Subject: [PATCH v2 00/10] Kconfig vs. default devices
Date: Wed, 8 Feb 2023 16:26:44 -0300

v2:
Applying the feedback received, all small tweaks.

Patch 6 still needs consensus on whether to apply the fix to Kconfig
or elsewhere. Link to the previous version:
461ba038-31bf-49c4-758b-94ece36f136f@redhat.com">https://lore.kernel.org/r/461ba038-31bf-49c4-758b-94ece36f136f@redhat.com

changelog:

- patch 1: moved isa-parallel to a build time check like the other
           patches;
- patch 3: tweaked commit message;
- patch 7: removed the default from XLNX_USB_SUBSYS.

v1:
20230206140809.26028-1-farosas@suse.de">https://lore.kernel.org/r/20230206140809.26028-1-farosas@suse.de

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):
  hw/i386: Select CONFIG_PARALLEL for PC machines
  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 | 8 ++++----
 hw/usb/Kconfig  | 1 -
 3 files changed, 11 insertions(+), 5 deletions(-)

-- 
2.35.3




reply via email to

[Prev in Thread] Current Thread [Next in Thread]