Re: [patch] config language dep_* enhancements

Kai Germaschewski (kai@tp1.ruhr-uni-bochum.de)
Mon, 12 Aug 2002 09:46:53 -0500 (CDT)


On Mon, 12 Aug 2002, Greg Banks wrote:

> > > I'm pleased to see that you have preserved those semantics. There
> > > are many places in the corpus where a dep_* lists as a dependency a
> > > variable which is not defined until later, or is only defined in
> > > some architectures, or is never defined. Earlier today I tweaked up
> > > gcml2 to detect them and found 260 in 2.5.29.
> >
> > You give me too much credit. The main motivation for dropping the '$'
> > was to make possible the "" == "n" semantics. That the patch failed
> > to do so was accident, not design.
>
> Ah, well that's more disturbing. Changing the existing semantics, regardless
> of how broken we all agree they are, is asking for a world of trouble. To
> pick an example, in 2.5.29 drivers/ide/Config.in:17 is
>
> dep_tristate ' SCSI emulation support' CONFIG_BLK_DEV_IDESCSI $CONFIG_ATAPI $CONFIG_BLK_DEV_IDE $CONFIG_SCSI
>
> But at this point in the menu tree for 14 of 17 architectures, CONFIG_SCSI has
> not yet been defined. The result is that CONFIG_BLK_DEV_IDESCSI only works
> in "make config" and "make allyesconfig" precisely because of the semantic that
> you wish to change.

But so the change would be a good thing, right? It would make the behavior
consistent between all configuration tools, CONFIG_BLK_DEV_IDESCSI would
be not selectable in either. So people would have to notice that this
statement is broken and fix it.

> > I know the current behavior is documented, but I had thought this was
> > because changing the behavior was not feasible due to our Bash-based
> > "JIT parsers".
>
> Yes, changing the behaviour is infeasible with shell-based parsers. However,
> there is now a body of rules which implictly depend on the semantics.

If they do, they should be fixed. And, as I pointed out before, it is
possible to fix even shell-based parsers.

> > Can you provide a rationale for why the current
> > behavior is desirable?
>
> I wouldn't call it "desirable". I would use words like "clunky", "congealed",
> "unorthogonal", "riddled with errors", and "very hard to fix" like the rest of
> the config language.

So you agree a bit of spring cleaning wouldn't hurt, right? ;)

> > It seems to me that it only encourages buggy
> > Config.in code (since "" == "n" in other contexts like the #defines),
>
> And "" != "n" in other contexts, like if [];then statements. Did I mention
> "unorthogonal" ?

Well, you're right here. Which makes me think of my original idea as to
define all CONFIG_* values to "n" unless they've explicitly been assign
another value before.

> The problem is that logic in config language is implicitly four-state, with
> the null or empty value being a separate value distinct from y, m and n.
> The fact that both "" and "n" mean "don't build this object" to kbuild doesn't
> mean that "" and "n" are the same thing. This isn't really obvious.
>
> One example where there is a semantic difference between "" and "n" would be
> an autoconfigurator, where "n" would mean "I have probed for this hardware and
> it is not present" but "" means something like "I have not probed".

The main usage currently is "make oldconfig", though .config may be a bit
confusing: Questions which have been answered before (even with "n") will
not be asked again, whereas for undefined symbols, the corresponding
question is put.

So I think the logic should really be tristate, "n","m","y", plus
additionally a list of CONFIG_* values which have been defined (as opposed
to just being "n" by default). This would get rid of the non-intuitive
behavior of dep_* and allow simplifying all the if [ == "n" || == "" ]
duplication. It's a bit cumbersome to implement in shell, but surely
possible.

Of course, this is a 2.5 change, though the only potential for breakage
are the dep_* statements which are arguably already broken. It shouldn't
be too hard to come up with a script which points out the dep_* statements
which reference symbols defined only later (or use gcml2, which I
understand can do that already?) to see how much breakage there may be.

--Kai

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/