[kbuild-devel] Re: 64bit clean drivers was Re: Linux 2.4.20-pre1
[Peter Samuelson] !y == n !m == n !n == y [Roman Zippel] I would define !m as m, e.g. it would allow dep_tristate CONFIG_OLD !$CONFIG_NEW dep_tristate CONFIG_NEW !$CONFIG_OLD You know, that never even occurred to me. Your scheme is not strictly logical, but it is much more practical, since it is perfect for expressing a relatively common (and currently awkward) case. I'm convinced. Now we have !y == n !m == m (significant for dep_tristate and dep_mbool) !n == n BTW, does anyone have a problem with my proposal (for 2.5, not necessarily 2.4) for '/dep_/s/ \$CONFIG/ CONFIG/g' ? That is, -dep_tristate CONFIG_FOO_X CONFIG_FOO CONFIG_BAR !CONFIG_BAZ +dep_tristate CONFIG_FOO_X $CONFIG_FOO $CONFIG_BAR !$CONFIG_BAZ Advantages: - the config files are more readable, especially when using ! - can support the old syntax with no extra code and most importantly - resolves the parsing difficulty with detecting an undefined value in dep_* statements. Currently the undefined value is documented as ignored, but try to avoid the situation. which leads to - allows us to drop all those 'define_bool CONFIG_FOO n' statements whose main purpose was to avoid the empty value Eh? I posted a patch earlier; it was trivial, despite having a syntax error in Configure (deleted a 'while...do', forgot the 'done') which only proves that I don't test stuff very rigorously. Menuconfig actually shrunk, due to factoring. If and when I get my head around xconfig, we'll see how ugly this stuff does or doesn't get, but then again, if xconfig were made uglier, would anyone notice? Peter --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] [patch] config language dep_* enhancements
G'day,
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 ;-).
I was a bit worried when I first saw the patch (after all, kconfig is held
together with spit and string) but on careful reading it's mostly doing the
right thing. Mostly.
Peter Samuelson wrote:
[Kai Germaschewski]
As you're hacking Configure anyway, what about fixing
dep_tristate ' ..' CONFIG_FOO $CONFIG_BAR,
[I wrote]
I've thought about that many times. I think the cleanest solution is
to deprecate the '$' entirely:
dep_tristate ' ..' CONFIG_FOO CONFIG_BAR
This applies to 2.4.20pre and (except changelog bits) to 2.5.30 with
offsets.
You're willing to potentially perturb 2.4?
I still haven't touched xconfig, because frankly it scares
me. The tkparse.c vs Peter match is well underway, stay tuned..
Good luck, it scares me too.
--- 2.4.20pre1/Documentation/kbuild/config-language.txt 2002-02-25
13:37:51.0 -0600
+++ 2.4.20pre1p/Documentation/kbuild/config-language.txt2002-08-08
23:10:44.0 -0500
@@ -84,8 +84,17 @@
to generate dependencies on individual CONFIG_* symbols instead of
making one massive dependency on include/linux/autoconf.h.
-A /dep/ is a dependency. Syntactically, it is a /word/. At run
-time, a /dep/ must evaluate to y, m, n, or .
+A /tristate/ is a single character in the set {y,m,n}.
+
+A /dep/ is a dependency. Syntactically, it is a /word/. It is
+either a /tristate/ or a /symbol/ (with an optional, but
+deprecated, prefix $). At run time, the /symbol/, if present,
+is expanded to produce a /tristate/. If the /symbol/ has not been
+defined, the /tristate/ will be n.
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.
+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.
--- 2.4.20pre1/scripts/Configure2001-07-02 15:56:40.0 -0500
+++ 2.4.20pre1p/scripts/Configure 2002-08-08 22:31:49.0 -0500
@@ -232,6 +241,28 @@
}
#
+# dep_calc reduces a dependency line down to a single char [ymn]
+#
+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 ?
+ esac
+ case $neg$arg in
+ m) cur_dep=m ;;
+ n|Ny|Nm) cur_dep=n; return ;;
+ esac
When CONFIG_FOO is undefined, !CONFIG_FOO and CONFIG_FOO are both ignored,
which is not consistent with the mention of ! in the explanations for the
dep_* statements. Perhaps you need to more carefully define the semantics
of the ! prefix.
Greg.
--
the price of civilisation today is a courageous willingness to prevail,
with force, if necessary, against whatever vicious and uncomprehending
enemies try to strike it down. - Roger Sandall, The Age, 28Sep2001.
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: 64bit clean drivers was Re: Linux 2.4.20-pre1
Peter Samuelson wrote: [Russell King] Erm, !n == n ??? Duh. I need some serious sleep. That wasn't the only semantically significant typo in my post, only the worst. Obviously, !n == y. So what is ! ? Greg. -- the price of civilisation today is a courageous willingness to prevail, with force, if necessary, against whatever vicious and uncomprehending enemies try to strike it down. - Roger Sandall, The Age, 28Sep2001. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] [patch] config language dep_* enhancements
Greg Banks [EMAIL PROTECTED] writes:
| --- 2.4.20pre1/scripts/Configure2001-07-02 15:56:40.0 -0500
| +++ 2.4.20pre1p/scripts/Configure 2002-08-08 22:31:49.0 -0500
| @@ -232,6 +241,28 @@
| }
|
| #
| +# dep_calc reduces a dependency line down to a single char [ymn]
| +#
| +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 ?
The Right Way to write that is like this, assuming that $arg has already
been verified to be a valid identifier:
eval arg=\$$arg
No need for further quoting.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [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
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
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
