Date:	Tue, 22 May 2007 20:43:00 +0530
From:	"Satyam Sharma" <satyam.sharma@...il.com>
To:	"Trent Piepho" <xyzzy@...akeasy.org>
Cc:	"Stefan Richter" <stefanr@...6.in-berlin.de>,
	"Adrian Bunk" <bunk@...sta.de>, "Sam Ravnborg" <sam@...nborg.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"Roman Zippel" <zippel@...ux-m68k.org>
Subject: Re: RFC: kconfig select warnings bogus?

Hi Trent,

On 5/21/07, Trent Piepho <xyzzy@...akeasy.org> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists