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

[Fabiano Rosas <farosas@suse.de>]

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.