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 :-)

--

[ message continues ]

On Sun, 27 Apr 2008 17:45:36 -0700 (PDT)

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

[ message continues ]

Arjan van de Ven wrote:
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.
--

[ message continues ]

From: Arjan van de Ven <arjan@infradead.org>

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

[ message continues ]

This should work.


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

--

[ message continues ]

From: Adrian Bunk <bunk@kernel.org>


We've hit this specifically with the intel iwlwifi wireless drivers

Select doesn't enable downstream dependencies, it just blindly turns
it on, non-modular.  That's not what we want at all.

--

[ message continues ]

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 

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

--

[ message continues ]

From: Adrian Bunk <bunk@kernel.org>

Ok, thanks Adrian.
--

[ message continues ]