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

[Alex Bennée]

Thomas Huth <thuth@redhat.com> writes:

> On 08/02/2023 20.43, Philippe Mathieu-Daudé wrote:
>> 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."
>
> You're mis-quoting me here. That comment was made when we were talking
> about very arbitrary configs that likely nobody is going to use.
> Fabiano's series here is about the --without-default-devices configure
> option which everybody could add to their set of "configure" options
> easily.

Indeed - while trying to reduce the compile time I ran into this with a
plain --without-default-devices check. We also have in the meantime
introduced --with-devices-FOO so we can do minimal builds.

>
>  Thomas


-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro