Re: Consistency in Kconfig organization, depends / select


Jukka Rissanen
 

Hi Marcus,

On Mon, 2017-01-16 at 10:46 +0000, Marcus Shawcroft wrote:
Hi!

I noticed this review fly by:

https://gerrit.zephyrproject.org/r/#/c/9982/

Which essentially adjusts a Kconfig to have an SPI driver Kconfig
explicitly select a GPIO driver when it needs the GPIO driver.

Many, perhaps most of the dependence relationships between drivers
are
currently expressed using a Kconfig "depends" model rather than the
"select" model.

Over the last few months I've pondered the use of the "depends" model
rather than a "select" model.  Superficially the "select" model has a
number of user facing advantages over the "depends" model, ones that
spring to mind are:
- As a user I can just enable the high level components/drivers I
need
to solve the applications problem, all the dependencies get dragged
in
automatically.
If you use "select", then the dependencies of that select are not
selected by default. This makes "select" a bit cumbersome and error
prone to use IMHO. 

- As a user I don;t need to dig around in Kconfig to figure out which
config options I need  to first enable in order to get the actual
option I'm looking for to appear in the config menus (I've often
found
myself having to do this :-(.

Looking in the drivers tree, there are many driver dependencies that
IMHO would give a better user config experience if we adopted a
selects model instead of the current depend model, for example:
- *sensor* -> I2C.
- console -> serial
- flash -> spi
- spi -> gpio
- ethernet -> random

What do folks think about adopting a more aggressive use of 'select'
?

Cheers
/Marcus

Cheers,
Jukka

Join devel@lists.zephyrproject.org to automatically receive all group messages.