Re: [kbuild-devel] RFC: kernel config: new dependency syntax
Greg Banks wrote: [*] almost enough because I haven't implemented an 'else' directive. It would be trivial, but I'm not sure what to call it. 'else' itself is a shell primitive, so the shell-based parsers (Configure, Menuconfig) wouldn't like it. You will need to implement it. You could call it elsedep. Either if_dep, else_dep and end_dep _or ifdep, elsedep, enddep. Cheers, Brendan Simon. --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] RFC: kernel config: new dependency syntax
Brendan J Simon wrote: Greg Banks wrote: [*] almost enough because I haven't implemented an 'else' directive. It would be trivial, but I'm not sure what to call it. 'else' itself is a shell primitive, so the shell-based parsers (Configure, Menuconfig) wouldn't like it. You will need to implement it. You could call it elsedep. Either if_dep, else_dep and end_dep _or ifdep, elsedep, enddep. Yes, the _s should be consistent. How about using fi instead of end for consistency with the current scheme? if_dep else_dep fi_dep 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: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] RFC: kernel config: new dependency syntax
Peter Samuelson wrote: * 'or' placed between dependencies functions as a logical OR, and takes very low precedence. This complements the implicit AND performed between every pair of dependencies. x or x - x, for any x n or m == m or n - m n or y == y or n - y m or y == y or m - y I don't like calling it or... It is error prone because it is a non binary system, thus can confuse the lazy developers. Better min. Also I don't like the construct if_dep that parse multiple lines. IMHO better a single line statment: if_dep ..cond.. then ..cml1_statment.. ciao giacomo * A=B evaluates to either Y or N, depending on whether A is logically equivalent to B. It has higher precedence than the ! operator. Thus: CONFIG_FOO=m evaluates to 'y' if CONFIG_FOO is m, 'n' otherwise CONFIG_BAR=n evaluates to 'y' if CONFIG_BAR is n or empty, 'n' otherwise !CONFIG_BAZ=y evaluates to 'n' if CONFIG_BAZ is y, 'y' otherwise This syntax is fully backward-compatible. Examples of use: if_dep CONFIG_X86 or CONFIG_X86_64 or CONFIG_IA64 bool 'ACPI support' CONFIG_ACPI endif if_dep CONFIG_SOUND !CONFIG_SOUND_ALSA source sound/oss/Config.in endif dep_tristate 'Adaptec (new driver)' CONFIG_AIC7XXX_NEW !CONFIG_AIC7XXX_OLD dep_tristate 'Adaptec (old driver)' CONFIG_AIC7XXX_OLD !CONFIG_AIC7XXX_NEW The one thing I wanted to specify but didn't is an 'else' statement. The problem is that I can't think what to call it - can't use 'else' because the shell-based parsers (Configure, Menuconfig) will choke on it. Any ideas? Any other comments? Am I going in totally the wrong direction? Peter --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] RFC: kernel config: new dependency syntax
[Brendan J Simon]
Either if_dep, else_dep and end_dep _or ifdep, elsedep, enddep.
I like it. My original if_dep was ifdep, but I thought people would
mistake it for the common verb 'ifdef' and misspell it that way. So I
vote for the _s.
[Greg Banks]
Yes, the _s should be consistent. How about using fi instead of
end for consistency with the current scheme?
H, not sure - the point is to get *away* from shell syntax. OTOH,
somehow fi_dep *does* seem more consistent than end_dep.
else_dep() is a simple matter of reversing the polarity of the guard.
Basically:
function else_dep () {
case $nest_ifdef in
'') {{{ syntax error: else without if }}} ;;
y|m) nest_ifdef=n ;;
n) nest_ifdef=y ;;
esac
}
I suppose Bourne-feature-completeness would demand 'elif_dep' as well.
That's not hard either, but is it overkill? I know Linus hates
overengineering, and to a much lesser extent so do I.
Peter
---
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] RFC: kernel config: new dependency syntax
Greg, in regards to another question you had - no I don't think there
is value in having a variant if statement that treats 'm' differently.
You can already get the same effect by using 'CONFIG_FOO=y' or
'CONFIG_FOO=m' instead of plain 'CONFIG_FOO'.
You are much better than I at finding examples of weird stuff in the
config system, though, so let me know if this doesn't cover all cases.
[I wrote]
else_dep() is a simple matter of reversing the polarity of the guard.
No it's not - I just realised that this breaks nested if_dep.
I suppose Bourne-feature-completeness would demand 'elif_dep' as
well.
I also realised that else_dep and elif_dep are exactly the same except
that else_dep doesn't take a dep line. So else_dep now does double
duty:
if_dep CONFIG_FOO
...
else_dep CONFIG_BAR
...
else_dep CONFIG_BAZ !CONFIG_XYZZY
...
else_dep
...
fi_dep
Of course if one feels uncomfortable about an empty 'else_dep' line
one can always append a dummy 'y'.
Incremental patch (lightly tested) over the one earlier in the thread:
--- 2.5.31/scripts/Menuconfig 2002-08-15 03:57:59.0 -0500
+++ 2.5.31w/scripts/Menuconfig 2002-08-15 03:55:22.0 -0500
@@ -130,7 +130,7 @@
# Use boolean transforms, or nest conditionals.
function dep_calc () {
local neg arg ordep
- if [ $nest_ifdep = n ]; then
+ if [ $nest_ifdep = n -o $nest_ifdep = x ]; then
cur_dep=n;
return 1;
fi
@@ -171,7 +171,15 @@
nest_ifdep=$cur_dep
}
-function endif () {
+function else_dep () {
+ case $nest_ifdep in
+ y | m | x) nest_ifdep=x ;;
+ n) fi_dep; if_dep $@ ;;
+ *) ;; # syntax error: else without if, or similar
+ esac
+}
+
+function fi_dep () {
nest_ifdep=${nest_stack%%' '*}
nest_stack=${nest_stack#*' '}
}
---
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: [patch] config language dep_* enhancements
Hi, (Could you please fix your mailer? linux-m68k.org.com does not really exist.) On Thu, 15 Aug 2002, Greg Banks wrote: The problems are really not simple, the current config language is very limited, [...] I don't think anyone who actually understands the config system would argue these points, but we are limited by practical constraints to making incremental improvements only. That's fine with me, but nonetheless I'd really like to know where it will go to. Just fixing the easy problems is simple, but so far I haven't seen any plan on how to fix the hard problems. Anyone starting to fix all the problems should have at least some ideas how to do it and I'd really like to hear them. I don't want to discourage anyone, but he should understand the complete problem first before going for the easy targets. bye, Roman --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: [patch] config language dep_* enhancements
On Thu, 15 Aug 2002, Roman Zippel wrote: I don't think anyone who actually understands the config system would argue these points, but we are limited by practical constraints to making incremental improvements only. That's fine with me, but nonetheless I'd really like to know where it will go to. Just fixing the easy problems is simple, but so far I haven't seen any plan on how to fix the hard problems. Anyone starting to fix all the problems should have at least some ideas how to do it and I'd really like to hear them. I don't want to discourage anyone, but he should understand the complete problem first before going for the easy targets. I think concentrating on the small gotchas for now is a good thing. Surely not all conceptual problems are fixable easily, they probably need to be done in conjunction with switching to a common parser etc. (Note: this switch to a new parser should happen with no change to the config.in format or semantics, in order to fit the Linux/Linus way of doing things). However, I think it is too late in 2.5 for these kind of big changes. That doesn't mean that fixing bugs, of which there are plenty, and small improvements like == n where possible shouldn't be done. If nothing else, it will at least give a better starting point for more elaborate work later. --Kai --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Get rid of shell based Config.in parsers?
On Wed, 14 Aug 2002, Sam Ravnborg wrote: Where comes the requirement that we shall keep the existing shell based config parsers? I use them exclusively. It is far and away the most convenient parsing - just to do make oldconfig (possibly by making changes by hand to the .config file first). As far as I'm personally concerned, the shell parsers are the _only_ parser that really matter. So if you want to replace them with something else, that something else had better be pretty much perfect and not take all that long to build. Linus --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] RFC: kernel config: new dependency syntax
[Giacomo A. Catenazzi] I don't like calling it or... It is error prone because it is a non binary system, thus can confuse the lazy developers. I had to call it something. I for one think 'or' is quite intuitive here. If you insist that OR can only be done on binary values, think of 'y'==3 and 'm'==1. Better min. You mean max. min would in this case be a logical AND. But nobody thinks of max as an infix operator, and infix is IMO the most natural way to express a low-precedence operator without explicit grouping. Also I don't like the construct if_dep that parse multiple lines. IMHO better a single line statment: if_dep ..cond.. then ..cml1_statment.. My goal here is to replace the current 'if' statement. I think the current syntax is ugly and looks too much like Bourne shell (which of course is not a coincidence). As such, a multi-line construct is necessary. There are some passages of kernel Config.in files that have 20 or 30 lines under a single conditional. Changing those to be line-by-line is not really an option. Peter --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] RFC: kernel config: new dependency syntax
[Kai Germaschewski] Honestly, I do not like this. It's probably the best that can be done in shell, but I think it's ugly and not intuitive. I accept that it is not pretty. But unless we can switch to mconfig or gcml2 or some other static parser for everything, we will need shell-parsable syntax. And I submit that the current pseudo-shell syntax using if [ ] is quite a bit uglier and less intuitive. The shell-syntax if [ ] might seem intuitive at first glance, if you already know the Bourne shell, but that leads you into the trap that you can use *any* Bourne shell syntax there, which of course you can't. For example, someone might try the following: if [ $CONFIG_FOO = y ] || [ $CONFIG_BAR = y ]; then or perhaps, being ksh wizards, they think they can use if [[ $CONFIG_FOO = y || $CONFIG_BAR = y ]]; then Oops. By using *exactly* the same syntax for dep_* and if_dep, I hope to *reduce* the confusion of exactly what functionality is or is not available. Currently we have a *completely arbitrary* subset of Bourne shell and /bin/test, which is Not Good. It is also, I believe, easier to implement a static parser for my 'if' replacement, since the dependency line bit can share common code. My Menuconfig patch illustrates this. CONFIG_FOO=m evaluates to 'y' if CONFIG_FOO is m, 'n' otherwise CONFIG_BAR=n evaluates to 'y' if CONFIG_BAR is n or empty, 'n' otherwise !CONFIG_BAZ=y evaluates to 'n' if CONFIG_BAZ is y, 'y' otherwise Hmmh, personally I don't like all these logical operations on tristates, since they are not intuitive (at least for me). Note that the 'if_dep' statement is effectively boolean anyway, so the dependency line gets implicitly cast to bool, just as with dep_mbool. So the fact that 'm' is distinct from 'y' is really only important for dep_bool and dep_tristate. If people want to avoid using ! or 'or' or the '=x' suffix in dep_bool and dep_tristate lines - well, they've been getting along fine without them for years. This is similar to the fact that you can mix and match '-o' and '-a' in our current if statements, but the precedence rules are unclear, so nobody ever actually does it. We use nested 'if' statements instead. As for the ! operator, I originally suggested that !m==n, but it was pointed out to me that !m==m is more practical, since it corresponds to a common case in config code. In these Boolean relations there is more than one truth value - but note that the same is true in C. !!x does not in general yield x, and I don't think this confuses most people. They all make sense, and I know we have them in thep dep_* lines already, but I'm not sure we want to spread them further. It's the cleanest syntax I can come up with - including the status quo, which if you didn't know it was supposed to be an imitation of Bourne shell, would look completely bizarre. Perhaps you prefer the status quo, for the simple reason that if we have to have something ugly it may as well be a *familiar* ugliness. That is a vald argument, though I disagree with it. Or do you have an alternative new syntax to propose? When we get real tristates for $CONFIG_, every case can be tested for in one comparison (= 'y', = 'm', = 'n', != 'n' etc), and I think the result looks clearer than having to remember the subtleties of a tristate or. I don't follow. What do you mean by real tristates for $CONFIG_? if_dep CONFIG_X86 or CONFIG_X86_64 or CONFIG_IA64 bool 'ACPI support' CONFIG_ACPI endif if_dep CONFIG_SOUND !CONFIG_SOUND_ALSA source sound/oss/Config.in endif I don't like this, and I think it is actually the kind of change which is hard to get past Linus, since it just looks ugly. Once again, we're comparing the above against if [ $CONFIG_X86 = y -o $CONFIG_X86_64 = y -o \ $CONFIG_IA64 = y ]; then bool 'ACPI support' CONFIG_ACPI fi if [ $CONFIG_SOUND = y -o $CONFIG_SOUND = m ]; then if [ $CONFIG_SOUND_ALSA != y -a $CONFIG_SOUND_ALSA != m ]; then source sound/oss/Config.in fi fi I realize this limitation is largely caused by using shell as the interpreter, but in this case I'd prefer to drop using shell, I think we all agree that a using common parser later would be a good thing anyway, and that really does not need to be written in shell. If we can get mconfig or similar into the standard kernel and displace Configure and Menuconfig, we'll certainly have a lot more options. I agree that it would be nice to drop the requirement for shell parsing. I just don't know if it's a realistic goal, especially before 2.6. Peter --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ kbuild-devel mailing list [EMAIL PROTECTED]
Re: [kbuild-devel] RFC: kernel config: new dependency syntax
Peter Samuelson wrote: [Giacomo A. Catenazzi] I don't like calling it or... It is error prone because it is a non binary system, thus can confuse the lazy developers. [...]But nobody thinks of max as an infix operator, and infix is IMO the most natural way to express a low-precedence operator without explicit grouping. Also I don't like the construct if_dep that parse multiple lines. IMHO better a single line statment: if_dep ..cond.. then ..cml1_statment.. My goal here is to replace the current 'if' statement. [...] I agree with Peter, a design goal should be to have an easy textual mapping from the existing if statements to the new syntax, which preserved semantics. So, multi-line constructs and infix operators would be required. 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: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] RFC: kernel config: new dependency syntax
[Greg Banks]
I was thinking that with your proposed syntax we'd have a large
level of compatibility in both syntax and semantics between if_dep
and dep_bool, much more so than with if and dep_bool
As you said the other day, This is not a coincidence. (:
But technically, if_dep corresponds to dep_mbool, not dep_bool.
so people would be tempted to start moving code between them,
e.g. changing backwards and forwards between
if_dep CONFIG_EXPERIMENTAL
bool 'foo' CONFIG_FOO
fi_dep
...and...
dep_bool 'foo' CONFIG_FOO CONFIG_EXPERIMENTAL
Since CONFIG_EXPERIMENTAL is itself a bool, the ambiguity doesn't come
up. But I see your point.
if_dep interprets both 'y' and 'm' as True, just as dep_mbool does. I
considered having 'm' mean False, but in the real world I think
dep_mbool is more useful than dep_bool.
If you really want dep_bool semantics you can still get them:
if_dep CONFIG_EXPERIMENTAL=y
bool 'foo' CONFIG_FOO
fi_dep
It is my opinion that most people outside the kbuild-devel list
probably do not understand the difference between dep_bool and
dep_mbool, or if they do understand, they probably do not know for
sure which is which, without looking it up. I don't want to impose
the same learning curve on if_dep. Really, dep_mbool usually *is*
what you want, since it is typically used for sub-features of things
that can be modules.
Yes, you need a condition stack and the else inverts only the top of the
stack. GCML2 does something like this.
Yep, that's basically what I did, except that my stack is cumulative
so the 'else' has to handle that.
I don't see any value to adding an else-if ability. Like parentheses in
if_dep expressions, it's more complexity than is justified by the logic.
You're probably right. It was just that, since an empty dependency
line evaluates to y, the syntax for elif falls out pretty much for
free. User perception of total complexity is not free, though, so
I'll probably drop it.
Here's an interesting idea which could be powerful but might, once
again, cause too much confusion to be practical: what about an if_dep
variant that has the power to restrict the entire block to {m,n}?
This is the analogue of dep_tristate, and is something the current
if-statement can't do. If set to 'm', it would *not* affect dep_mbool
statements inside the block, but it *would* disable bool and dep_bool,
and restict tristate / dep_tristate to {m,n}.
This would enable some serious cleanup in e.g. drivers/scsi/Config.in,
where almost every line is individually dependent on CONFIG_SCSI. The
more I think about it, the more useful this starts to sound.
Peter
---
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: [patch] config language dep_* enhancements
Roman Zippel wrote: Hi, (Could you please fix your mailer? linux-m68k.org.com does not really exist.) I believe the problem is upstream of the machine I control. I'll see what I can do. That's fine with me, but nonetheless I'd really like to know where it will go to. Just fixing the easy problems is simple, but so far I haven't seen any plan on how to fix the hard problems. Anyone starting to fix all the problems should have at least some ideas how to do it and I'd really like to hear them. I don't want to discourage anyone, but he should understand the complete problem first before going for the easy targets. The easy targets being done now are mostly things that I believe would need to be done regardless of the eventual strategy, be it a) do nothing b) make the existing system suck less c) replace the parsers and keep the rules d) replace everything. For any of these strategies to be successful you would need to start with a clean clear and consistent rules corpus. Remember how people were complaining that ESR couldn't prove that the CML2 rules corpus did the same things as the CML1 rules corpus? One of the reasons was that the CML1 rules corpus is so screwed that's its impossible for either a human or a machine to figure out what was supposed to happen and whether what was actually happening was deliberate. Roman, I believe the exactly same issue will apply to your config system too, because it uses a machine translation step from CML1. GCML2's syntax checker started life as a CML1-to-CML2 converter (inspired by your work), but I gave up on machine translating because it would be GIGO. This is why I'm not talking about replacing shell based parsers yet. First we need to get a rules corpus for which it is possible to create a parser which can parse cleanly, consistently, and correctly. 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: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: [patch] config language dep_* enhancements
[John Alvord] I've been puzzling about this problem and the CML2 trainwreck. Maybe we can used advanced tools to remove the many bugs and inconsistancies and then switch to a better config tool. That's exactly what we're trying to do. Greg has the advanced consistency checking, and I've been trying to remove ambiguities and warts in the current rule corpus, and simultaneously come up with some extensions to the current language that will let us remove *more* warts. The extensions are designed to completely supplant certain existing constructs which I consider ugly and difficult to parse. To paraphrase Orwell: it was intended that when Newspeak had been adopted once and for all and Oldspeak forgotten, a buggy parser should be literally unimplementable, at least so far as implementation is dependent on clear syntax and reasonable semantics. Peter --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
