Re: Recursive dependency for SAA7134 in 2.6.15-rc7

[Jean Delvare <khali@linux-fr.org>]

Hi Roman,

> On Saturday 31 December 2005 19:39, Jean Delvare wrote:
> 
> > So I believe that "choice" is an interesting Kconfig feature when used
> > with boolean options, but with modules I am not convinced, especially
> > when these modules have different dependencies.
> 
> Well, I'm always open to suggestions (or even better patches) to improve 
> tristate choices. Such interdependent options have to be done via a choice 
> group, so they are correctly handled by kconfig, otherwise you have 
> to live with the current compromise. OTOH how they are mapped to the user 
> interface is easily changeable.

What I like with the current "compromise" in the SAA1734 case is that,
if the user has only OSS or only ALSA enabled in the sound menu, then
he/she only sees one available module for SAA7134 sound support. It
keeps the configuration interface as simple as it can be. While when
using a choice, the user will still be presented a pre-item/menu, with a
single choice in there. This is what I think is confusing.

If "choice" could fall back to a simple option when the dependencies
are such that only once choice is actually possible, I think it would
improve the situation, in the case of the SAA7134. But I lack time to
propose an actual patch implementing this, and I also did not
investigate to see what it would do for the other use cases of "choice"
in the current kernel tree. Lastly I guess that some people may find it
even more confusing if things were done the way I suggest - it's really
a matter of personal opinion at this point.

Given that there are only a few use cases of "choice" with tri-state
options, it might be just as easy to leave things as is and do with
what we have.

Thanks,
-- 
Jean Delvare