Re: RFC: kconfig select warnings bogus?

[Stefan Richter <stefanr@s5r6.in-berlin.de>]

Satyam Sharma wrote:
> I was only answering your *completely misplaced and
> incorrect* original comment against the patch where you claimed
> that the patch was "totally wrong" because of the way it removed
> the "select" ... etc ...

I believe I have explained why I labeled it as totally wrong.

> And remember, like I said already, the whole _idea_ is such arch-
> specific helper code be not mentioned from arch-agnostic Kconfig
> files. You may not like it, but this is the standard / most common way
> such cases are handled for tons of other cases in arch/...

The standard and maintainable way (for drivers at least) is

config A
	bool-or-tristate "option A"
	depends on !PLATFORM_X || HELPER_N_ON_PLATFORM_X

It is not a matter of me disliking something.  It's a matter of that we
can easily determine what A needs, but have a hard time to determine and
maintain the dependencies in the reverse way.

BTW, if A needs platform-specific helper N, then A is not
platform-agnostic.  If A is desired to be platform-agnostic, then either
A has to be implemented independently of N or N has to be made available
on all platforms.

> Which is why Adrian's way of solving this (shifting all such
> arch-specific helper symbols also to drivers/... and then using depends
> on select on it) is not viable.

I'm not advocating any specific fixes or pseudo-fixes.  I'm advocating
the notation of dependencies in the direction "A requires B".

Since you mention "select":  My opinion about the "select" dialect of
"depends on" is that the UIs should be improved and "select" should be
removed from the Kconfig language.  What do we "select"?  Typically we
"select" an option on which /n/ other options depend on but which itself
does depend on none or few options higher up.  The UIs could be able to
figure this out for themselves, or if necessary by a hint tacked onto
library-type options.  That is, instead of

	config A
		tristate "driver A"
		select L

	config B
		tristate "driver B"
		select L

	config L
		tristate "library L"

write

	config A
		tristate "driver A"
		depends on L

	config B
		tristate "driver B"
		depends on L

	config L
		tristate "library L"
		hint THIS_IS_A_LIBRARY

Now let UIs "make oldconfig", "make menuconfig", "make randconfig" deal
with the hint or ignore the hint --- according to the purpose and
usability requirements of the respective UI.  The "hint
THIS_IS_SOMETHING" isn't even necessary in many cases to detect roles of
options, because their position in the dependency graph is already
saying something about it.

These things really should be shifted into the UIs as much as possible,
because we can have a number of special-purpose UIs but we want
all-purpose Kconfig files.
-- 
Stefan Richter
-=====-=-=== -=-= =-=--
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/