Kconfig 'depend' vs. 'select'

Kconfig 'depend' vs. 'select'

[David Miller]

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.

2) If you say "select" on some subsystem, to try and solve the
   conflict in #1, that doesn't take care of any dependencies the
   subsystem may have.  This can also break the build.

There should be an elegant solution to this problem.  But I don't
think changing how 'select' or 'depend' works is it.

'depend' as it stands now works fine for purely boolean things like
"this architecture has or wants FOO".  There is no reason to remove
it or change it's semantics, I think.

So my initial suggestion is a new construct, that is like 'depend' but
takes care about the modular'ness.

It would scan all things depending upon a given target, and make sure
that most strict requirement of built-in vs. modular is adhered to.

So if you had, for example:

config FOO_API
	...

and then you had two drivers:

config DRIVER1
	tristate ...
	needs FOO_API

config DRIVER2
	tristate ...
	needs FOO_API

and DRIVER1 was built modular but DRIVER2 was built-in,
the Kconfig system would make sure FOO_API were built-in.

The "needs" name and syntax is just something arbitrary I came up
with, don't take it too seriously :-)

Re: Kconfig 'depend' vs. 'select'

[Arjan van de Ven]

On Sun, 27 Apr 2008 17:45:36 -0700 (PDT)
David Miller <davem@davemloft.net> 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.
> 
> 2) If you say "select" on some subsystem, to try and solve the
>    conflict in #1, that doesn't take care of any dependencies the
>    subsystem may have.  This can also break the build.
> 
> There should be an elegant solution to this problem.  But I don't
> think changing how 'select' or 'depend' works is it.
> 
> 'depend' as it stands now works fine for purely boolean things like
> "this architecture has or wants FOO".  There is no reason to remove
> it or change it's semantics, I think.

how far would "if you DEPENDS on FOO, and FOO is =m, you can only be =m or =n" get us?
or are there hidden traps on this?
(the hard case is if a non-tristate DEPENDS on a tristate, but... that's a trap anyway)

-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: Kconfig 'depend' vs. 'select'

[Seewer Philippe]

Arjan van de Ven wrote:
[snip]
> how far would "if you DEPENDS on FOO, and FOO is =m, you can only be =m or =n" get us?
> or are there hidden traps on this?
> (the hard case is if a non-tristate DEPENDS on a tristate, but... that's a trap anyway)
I guess it depends on the (use-)case. But in general I'd like a system 
like that, especially if it would spew out warnings and errors for cases 
like the one mentioned.

Re: Kconfig 'depend' vs. 'select'

[Adrian Bunk]

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.

Can you give an example of the problem you are thinking of?

> So if you had, for example:
> 
> config FOO_API
> 	...
> 
> and then you had two drivers:
> 
> config DRIVER1
> 	tristate ...
> 	needs FOO_API
> 
> config DRIVER2
> 	tristate ...
> 	needs FOO_API
> 
> and DRIVER1 was built modular but DRIVER2 was built-in,
> the Kconfig system would make sure FOO_API were built-in.
> 
> The "needs" name and syntax is just something arbitrary I came up
> with, don't take it too seriously :-)

What about "select"?

That's exactly what it's doing.

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

Re: Kconfig 'depend' vs. 'select'

[David Miller]

From: Arjan van de Ven <arjan@infradead.org>
Date: Sun, 27 Apr 2008 21:58:40 -0700

> how far would "if you DEPENDS on FOO, and FOO is =m, you can only be
> =m or =n" get us?  or are there hidden traps on this?  (the hard
> case is if a non-tristate DEPENDS on a tristate, but... that's a
> trap anyway)

We want to avoid the problem of users having to sift through the dependency
chain just to figure something like that out.

It's rediculious to require a user to know if the obscure LEDS
subsystem is already set modular or not, for some unrelated reason, in
order to figure out how to build the wireless driver they want
statically into the kernel.

The whole idea behind my suggestion is that the user doesn't have
to know any of this implementation crap.  They just say "I want
wireless, and I want wireless driver X built statically into my
kernel, I don't care how you do it."

Re: Kconfig 'depend' vs. 'select'

[David Miller]

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.

> 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.

Re: Kconfig 'depend' vs. 'select'

[Adrian Bunk]

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

Re: Kconfig 'depend' vs. 'select'

[David Miller]

From: Adrian Bunk <bunk@kernel.org>
Date: Mon, 28 Apr 2008 11:13:19 +0300

> 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

Ok, thanks Adrian.