Re: Kconfig 'depend' vs. 'select'
From: Adrian Bunk
Date: Mon Apr 28 2008 - 04:14:07 EST
On Sun, Apr 27, 2008 at 11:42:21PM -0700, David Miller wrote:
> From: Adrian Bunk <bunk@xxxxxxxxxx>
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/