Hi Trent,
On 5/21/07, Trent Piepho <[email protected]> wrote:
On Sun, 20 May 2007, Stefan Richter wrote:
> Trent Piepho wrote:
> > config A
> > bool "A"
> >
> > config B
> > bool "B"
> > depends on A
> >
> > config C
> > bool "C"
> > select B
> >
> > In this case, it's possible to turn C on and A off. B will be on, even
> > though it depends on A and A is off.
> >
> > The kconfig docs say that "B.. depends on A" sets the maximum value of B
> > to be that of A. Since A=0, the max value of B is 0.
> >
> > The kconfig docs also say that "C.. select B" sets the minimum value of B
> > to be that of C. Since C=2, the minimum value of B is 2.
> >
> > So we have B>=2 and B<=0, which is obviously impossible. Yet *config has
> > no problem with this, and will set B=2 even the 'depends' means B must be
> > 0. It seems like "select" will override any other dependencies.
>
> If that's so, then we have /a/ an incomplete definition of the Kconfig
> language (what is supposed to happen if "select" attempts to set an
> impossible value?) and /b/ a bug in the make xyzconfig programs (they
> generate invalid configs).
This came up when I was working on the v4l-dvb tree's out of kernel build
system. It uses the same Kconfig files, but I've created a config system in
perl to parse and evaluate them. It will disable options that the kernel
config programs allow, and it is because I'm treating this situation
differently: Since "B" is disabled because "A" is off, "C" must also be
disabled.
Yeah, this is the classic "select" trap.
Another way of dealing with this would be to have 'select' follow the
dependency chain back up. Turning on C selects B, B depends on A, so A is
also selected.
You're right ... we'd discussed this earlier in:
http://lkml.org/lkml/2007/5/16/257
and http://lkml.org/lkml/2007/5/16/237
Also, because dependencies are of two types, those that _can_ be
meaningfully selected and those that can't, so we could select _all_
grand-parent dependencies A's of C when user picks C if they are all
selectable, but just refuse to proceed to even pick C itself if _any_
grand-parent dependency A of C is not a "select"able dependency.
i.e., a mix of the two solutions you mentioned above.
One problem with this is that "depends on" can take complex expressions.
Finding the solution is NP complete, which likely isn't a problem for the
sizes of realistic Kconfig files. But there could easily be multiple
solutions, so which one is the right one?
Yes, the real problem is when a "depends on" somewhere along the
dependency tree has a || somewhere in it -- so we don't exactly know which
branch to follow from that point when creating the dependency tree. But I
suspect this shouldn't really be such a show-stopper ... I'll see if I can look
into scripts/kconfig/*.c to try and implement something of this sort.
Cheers,
Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
