Re: kconfig - a suggestion how to fix the select issue

[Adrian Bunk]

On Sun, May 04, 2008 at 02:17:47PM +0200, Sam Ravnborg wrote:
> > > > > > 
> > > > > > 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.
> > 
> > I understand what you are saying.
> > 
> > The problem is that with A=m, C=y built-in code enabled by C cannot 
> > access the code enabled by A which can result in a build error.
> 
> That is a different type of issue which would most likely
> be solved by a "depends on A == y"

So feature C in driver B won't be enabled in allmodconfig or 
distribution kernels?

> > > > 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.
> > 
> > I know I'm bad at the syntax when I'm not trying stuff myself.
> > 	depends on !B || !X86
> > is the same and should be the correct syntax.
> > 
> > Or make it just
> > 	depends on !B
> > 
> > The problem is not the syntax, the problem is whether C should be 
> > visible, and what happens if the user enables it.
> OK - lets analyse this.
> B is visible (because A is y)
> D is visible (because B is n)
> E is visible
> 
> So per the definition C is visible.
> If user choose 'C' then user will be prompted to choose B
> due to the "require B".
> User now set B equal to 'y' and we have following situation:
> B is visible (because A is y)
> D is invisible (because B is y)
> E is visible
> So per definiton C is still visible.
> So user is now prompted to chose C.
> 
> 
> On the other hand had we had a:
> config C
> 	bool "c"
> 	depends on D
> 	requires B
> 
> Then when user set B equal 'y' user no longer
> are offered the possibility to chose 'C' as it is no
> longer visible.

Do you want in this case show the user the option C that can never be
enabled on this architecture or do you want to implement logic that can
prove whether any combination of values exists that allows C to be 
enabled?

> > > Are you trying to say that we cannot improve kconfig to better
> > > express the dependencies or what is your point?
> > 
> > My point is that all this "select follows depenencies" is easily said, 
> > but doing it in a way that it's better than what we have today is 
> > nontrivial.
> Which is exactly why I try to involve you in the discussion
> of a potential solution.

And pointing you at the possible problems is exactly what I'm doing.

> 	Sam

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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