[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.027 / U:2.572 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site