Re: Kconfig 'depend' vs. 'select'

[Adrian Bunk <bunk@kernel.org>]

On Sun, Apr 27, 2008 at 11:42:21PM -0700, David Miller wrote:
> From: Adrian Bunk <bunk@kernel.org>
> Date: Mon, 28 Apr 2008 09:39:54 +0300
> 
> > On Sun, Apr 27, 2008 at 05:45:36PM -0700, David Miller wrote:
> > > 
> > > I'm trying to stir up interest in solving a problem that seems to pop
> > > up frequently. :)
> > > 
> > > The short story is:
> > > 
> > > 1) If you say your driver "depend"s on a subsystem providing a set of
> > >    interfaces you need, this doesn't work properly if your driver is
> > >    marked built-in and that subsystem you need is modular for some
> > >    reason.
> > >...
> > 
> > This should work.
> 
> It doesn't.
> 
> > Can you give an example of the problem you are thinking of?
> 
> We've hit this specifically with the intel iwlwifi wireless drivers
> over the past week.

If you refer to Luca's patch, that's the select problem, not a problem 
with depends.

The only small pitfall with depends I'm aware of is if a bool driver 
depends on a tristate subsystem (same problem as what I describe below).

> > What about "select"?
> > 
> > That's exactly what it's doing.
> 
> Select doesn't enable downstream dependencies, it just blindly turns
> it on, non-modular.  That's not what we want at all.

The non-modular is only true for "bool selects tristate".

You are talking about things like:

config IWL4965_LEDS
        bool "Enable LEDS features in iwl4965 driver"
        select LEDS_CLASS

The problem here is that from a kconfig perspective IWL4965_LEDS could 
as well be an own driver you want for some reason non-modular.

The solution is to do the following instead:

config IWL4965
        tristate "Intel Wireless WiFi 4965AGN"
	select LEDS_CLASS if IWL4965_LEDS

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed