lkml.org 
[lkml]   [2008]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: kconfig - a suggestion how to fix the select issue
On Sun, May 04, 2008 at 12:04:29PM +0300, Adrian Bunk wrote:
> On Sun, May 04, 2008 at 10:27:32AM +0200, Sam Ravnborg wrote:
> > On Sun, May 04, 2008 at 11:11:45AM +0300, Adrian Bunk wrote:
> > > On Sun, May 04, 2008 at 09:10:41AM +0200, Sam Ravnborg wrote:
> > > >...
> > > >
> > > > config A
> > > > bool "a"
> > > >
> > > > config B
> > > > bool "b"
> > > > depends on A
> > > >
> > > > config C
> > > > bool "c"
> > > > require B
> > > >
> > > > The require dependency will have impact on visibility.
> > > > C shall only be visible if all symbols it require are
> > > > visible. Note that visible does not imply 'chosen'.
> > > > In this case C would be visible when A is chosen.
> > > >
> > > > When the user then choose C and B is not chosen
> > > > then the user is prompted to choose B.
> > > >
> > > > So user has to chose B in order to have C chosen.
> > > >...
> > > > Comments?
> > >
> > >
> > > Given:
> > >
> > > config A
> > > tristate "a"
> > >
> > > config B
> > > tristate "b"
> > > depends on A
> > >
> > > config C
> > > bool "c"
> > > require B
> > >
> > > CONFIG_A=m
> > >
> > >
> > > Will C be visible?
> > If you followed my description then you would see
> > that the visibility of C are determineded by the dependencies
> > of C (none in this case) and the dependencies of the symbol
> > it requires. In this case B. B dpens on A and A equals m so B is
> > visible thus C is visible.
>
> *shudder*
So let me explain it with some other words:
B is visible because A=m
C is visible because B is visible.
Simple.

>
> > > The underlying problem is that we use bool for two different cases:
> > > - non-modular driver (answer would be "no")
> > > - enable feature in driver (answer would be "depends on the value of D")
> > Lets try to agree on the semantics with bools first please.
> > When we have that in place lets extend it to modular - OK?
>
> I doubt the "extension" works this way since most of the interesting
> cases are with tristates.
>
> But OK, here's some fun with bools:
>
> config X86
> def_bool y
>
> config A
> bool "a"
>
> config B
> bool "b"
> depends on A
>
> config D
> bool "d"
> depends on !B if X86
>
> config E
> bool "e"
>
> config C
> bool "c"
> depends on D || E
> requires B
>
> Given:
> - CONFIG_A=y
> - CONFIG_B=n
> - CONFIG_D=y
> - CONFIG_E=n
>
> Will C be visible?
The above has a syntax error. A 'depends on' cannot have an
if caluse.
And I did not get your point either.

Are you trying to say that we cannot improve kconfig to better
express the dependencies or what is your point?

Puzzeled...

Sam


\
 
 \ /
  Last update: 2008-05-04 12:41    [W:0.054 / U:0.368 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site