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