[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 00/10] Kconfig vs. default devices
From: |
Fabiano Rosas |
Subject: |
Re: [PATCH v2 00/10] Kconfig vs. default devices |
Date: |
Wed, 08 Feb 2023 17:11:14 -0300 |
Philippe Mathieu-Daudé <philmd@linaro.org> writes:
> 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."
>
> [*]
> https://lore.kernel.org/qemu-devel/81aca179-4320-f00b-d9dc-7eca449ebce7@redhat.com/
If we're talking about turning the defaults off
(--without-default-devices), we already have that in the CI, we just
cannot ensure that it works because we cannot run 'make check' on
it. I'm just trying to improve that situation.
(not sure if that is clear, but this goes along with this other series
20230208194700.11035-1-farosas@suse.de">https://lore.kernel.org/r/20230208194700.11035-1-farosas@suse.de to fix
make check)
If we're talking about general fiddling with CONFIGS, then I'm inclined
to agree with Thomas that the CI doesn't need to test every single
combination. However, it's a basic maintenance task to ensure that if
your project has toggles, that they can actually be toggled.
As for use-cases, I don't have a specific one for disabling all the
defaults. For individual CONFIGs I would like to be able to produce a
slimmer build sometime in the distant future once we untangle everything
that's tangled today.
- Re: [PATCH v2 01/10] hw/i386: Select CONFIG_PARALLEL for PC machines, (continued)
- [PATCH v2 04/10] hw/i386: Select E1000_PCI for i440fx, Fabiano Rosas, 2023/02/08
- [PATCH v2 07/10] hw/arm: Select XLNX_USB_SUBSYS for xlnx-zcu102 machine, Fabiano Rosas, 2023/02/08
- [PATCH v2 08/10] hw/arm: Select GICV3_TCG for sbsa-ref machine, Fabiano Rosas, 2023/02/08
- [PATCH v2 03/10] hw/i386: Select VGA_PCI in Kconfig, Fabiano Rosas, 2023/02/08
- [PATCH v2 06/10] hw/arm: Select VIRTIO_BLK for virt machine, Fabiano Rosas, 2023/02/08
- [PATCH v2 05/10] hw/arm: Select VIRTIO_NET for virt machine, Fabiano Rosas, 2023/02/08
- [PATCH v2 09/10] hw/arm: Select e1000e for sbsa-ref machine, Fabiano Rosas, 2023/02/08
- [PATCH v2 10/10] hw/arm: Select VGA_PCI for sbsa-ref machine, Fabiano Rosas, 2023/02/08
- Re: [PATCH v2 00/10] Kconfig vs. default devices, Philippe Mathieu-Daudé, 2023/02/08