[Greg Banks]
> I like the basic idea here, and I'm pleased that someone has the
> courage to tackle some of the brokenness of the kconfig language (if
> only because it will provide me with a precedent when I try to
> submit some of my patches ;-).
Thanks for the feedback. (:
> > This applies to 2.4.20pre and (except changelog bits) to 2.5.30 with
> > offsets.
>
> You're willing to potentially perturb 2.4?
This stuff is trivial enough, and easy enough to test, that I think it
could go in 2.4, yes. Obviously xconfig would need to be dealt with
in sync with the others, which I'm not doing during the prototyping /
idea-mongering stage.
> The last statement is inconsistent with the shell code and the
> explanations of the dep_* statements, which sensibly preserve the
> current semantics where an undefined symbol has a distinct fourth
> value which is not y, m or n.
>
> 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.
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". Can you provide a rationale for why the current
behavior is desirable? It seems to me that it only encourages buggy
Config.in code (since "" == "n" in other contexts like the #defines),
and I don't see any benefits other than that it's the status quo.
[Not to demean the status quo - in 2.4 it is probably appropriate.]
> > + In addition, the /dep/ may have a prefix "!", which negates the
> > + sense of the /tristate/: "!y" and "!m" reduce to "n", and "!n"
> > + reduces to "y".
>
> Perhaps "negates" isn't quite the right word in four-state logic.
I wasn't sure what else to call it. Besides, as explained above, it's
intended (rightly or wrongly) to be 3-state logic, where two states
represent a form of "true". (:
Perhaps "the /dep/ may have a prefix "!", which transforms the
/tristate/ as follows: ..." This is particularly appropriate in light
of Roman's argument (which I buy) in favor of "!m" == "m".
> > +function dep_calc () {
> > + local neg arg
> > + cur_dep=y # return value
> > + for arg; do
> > + neg=;
> > + case "$arg" in
> > + !*) neg=N; arg=${arg#?} ;;
> > + esac
> > + case "$arg" in
> > + y|m|n) ;;
> > + *) arg=$(eval echo \$$arg) ;;
>
> Don't you want to check at this point that arg starts with CONFIG_?
> Also, how about quoting \$$arg ?
I suppose one could add sanity checks / diagnostics, but there are no
other valid cases, so that's all they would be. I'm not really trying
to produce a config.in 'lint' - leave that to the static parsers like
gcml2, xconfig and mconfig.
Peter
-
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/
This archive was generated by hypermail 2b29 : Thu Aug 15 2002 - 22:00:19 EST