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

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