Re: [Qemu-devel] QEMU and Kconfig

[Paolo Bonzini]

On 26/09/2018 16:15, Samuel Ortiz wrote:
> On Wed, Sep 26, 2018 at 03:36:07PM +0200, Paolo Bonzini wrote:
>> On 26/09/2018 10:32, Peter Maydell wrote:
>>> On 25 September 2018 at 10:26, Paolo Bonzini <address@hidden> wrote:
>>>> However, the Kconfig language is a good idea.  The idea is that
>>>> dependencies can be expressed:
>>>>
>>>> - as "select" whenever a board requires a device, or whenever a device
>>>> requires generic subsystem code in order to implement a controller for
>>>> that subsystem (e.g.: PC selects MC146818RTC, VIRTIO_SCSI selects SCSI)
>>>>
>>>> - as "depends on" whenever a device requires a bus (e.g.: SERIAL_PCI
>>>> depends on ISA)
>>>>
>>>> Putting the two things together, AHCI depends on PCI but it selects IDE.
>>>
>>> Could you clarify the distinction you're making here between
>>> these two kinds of dependency and what the top level user
>>> interface would be? I'm getting confused about why we need
>>> two -- I have a vague impression it depends on what the
>>> top level thing the user is selecting enablement of is,
>>> but maybe not ?
>>
>> Yes, exactly.  The user selects enablement of 1) boards 2) non-embedded
>> devices.  This mimics the level at which configuration is done today in
>> default-configs (it worked like this in 2013 during GSoC, and it is
>> still pretty much the same).  The idea is that everything else is
>> selected automatically by the configuration tool, but two different
>> paths are available depending on the desired defaults:
>>
>> - users of something (that is often "default n") use "select" to force
>> that configuration symbol to y
>>
>> - "depends on" is used for something that is (usually) default y, but
>> becomes n if the dependencies are missing
>>
>
> So "depends on" will go through the dependency graph and turn the config
> off if they're not entirely filled. But "select" just turns the config on
> regardless of the dependencies. Is that correct?

Almost; if there's a conflict between the decision from "depends on" and
"select" says, it's an error.  (Likewise if there's a conflict between
default-configs/ on one side, and "depends on"/"select" on the other).

This is different between kernel Kconfig and minikconf in my git repo.
The difference is because the Kconfig documentation warns against the
surprising effects of "select" blindly enabling the target symbol;
making minikconf stricter avoids those surprises.

Paolo