Messages in this thread | | | Date | Sun, 27 Apr 2008 17:45:36 -0700 (PDT) | Subject | Kconfig 'depend' vs. 'select' | From | 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 :-)
| |