Re: [2.6 patch] select FW_LOADER -> depends HOTPLUG

From: Adrian Bunk
Date: Thu Aug 12 2004 - 14:21:02 EST


On Thu, Aug 12, 2004 at 01:05:47AM +0200, Roman Zippel wrote:
>
>
> On Tue, 10 Aug 2004, Sam Ravnborg wrote:
>
> > On Tue, Aug 10, 2004 at 10:44:11AM +0200, Adrian Bunk wrote:
> > >
> > > I assume Sam thinks in the direction to let a symbol inherit the
> > > dependencies off all symbols it selects.
> > >
> > > E.g. in
> > >
> > > config A
> > > depends on B
> > >
> > > config C
> > > select A
> > depends on Z
> >
> > config Z
> > depends on Y
> > >
> > >
> > > C should be treated as if it would depend on B.
>
> There are two problems:
> 1) If A has no prompt it's not visible and so it's dependency is 'n', this
> means a number of symbols wouldn't be visible anymore.
> 2) It would change the bahaviour of symbols, which already do multiple
> selects (e.g. CONFIG_INET_AH), the select of CRYPTO would be useless, as
> it would only become visible, when CRYPTO is enabled. This means such
> selects wouldn't be possible anymore.
>
> This really needs a different (but similiar) mechanism, what I have in
> mind is something like this:
>
> config A
> autoselect
>
> config B
> depends on A
>
> For the visibility calculation A is set to y and A is automatically
> selected if any symbol, which depends on A, is enabled.
>...

How do you want to handle the following?

<-- snip -->

config FW_LOADER
tristate "Hotplug firmware loading support"
depends on HOTPLUG

config ATMEL
tristate "Atmel at76c50x chipset 802.11b support"
depends on NET_RADIO && EXPERIMENTAL
select FW_LOADER
select CRC32

<-- snip -->


We've been biten that often by cases like a "select I2C_ALGOBIT" without
a dependency on or a select of I2C and such cases are real issues that
need a proper handling.


> bye, Roman

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/