[lkml]   [2002]   [Aug]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] config language dep_* enhancements

[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 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 'lint' - leave that to the static parsers like
gcml2, xconfig and mconfig.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:27    [W:0.203 / U:0.744 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site