[Top][All Lists]

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

Re: [Qemu-devel] QEMU and Kconfig

From: Samuel Ortiz
Subject: Re: [Qemu-devel] QEMU and Kconfig
Date: Wed, 26 Sep 2018 16:15:18 +0200
User-agent: Mutt/1.10.1 (2018-07-13)

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.  Buses are in this family, and they are
> "default n" because you don't really need a bus implementation unless
> you have a controller device that exposes that bus.  Embedded devices
> are in this family too, because the board will just not work if the
> embedded device is not present in the QEMU binary.  Embedded device
> might be "default y", and then you have an error if the user forces the
> device to "n" but does not do the same on the board that embeds it.
> - "depends on" is used for something that is (usually) default y, but
> becomes n if the dependencies are missing.  In this case you want by
> default all PCI devices to be there if you have a PCI controller in your
> machine: PCI is "default n", the PCI controller "selects" PCI, the PCI
> devices are "default y" and "depend on" PCI.  However, if PCI is
> disabled because there is no PCI controller, then all PCI devices must
> be excluded from the binary, and there's no possibility of overriding
> that because the code would likely not compile at all.
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?


reply via email to

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