Re: [kbuild-devel] RFC: kernel config: new dependency syntax
[I wrote] I guess I wasn't quite clear: my current implementation is both visibility + value, not visibility only (like current if [ ]) or value only (like an earlier discussion of dep_if). [Greg Banks] Aha. I think you're going to be arguing uphill to get it in. Could be. Perhaps none of this will see the light of day. But, while I've designed it to replace the current syntax, it can coexist with it for as long as necessary. and easy to work around if not wanted. Not so sure about that. My Menuconfig patch still has one bug, which I'm still thinking about the best way to fix, so I can't properly test this stuff yet - but with the Config.in files I've dealt with so far, I haven't found it hard to work around this semantic difference. There are lots of instances of things like if [ $CONFIG_FOO = y -o $CONFIG_FOO = m ]; then dep_tristate 'Bar' CONFIG_BAR $CONFIG_FOO ... fi which can be replaced by dep_if CONFIG_FOO tristate 'Bar' CONFIG_BAR ... dep_fi but few, if any, instances of if [ $CONFIG_FOO = y -o $CONFIG_FOO = m ]; then tristate 'Bar' CONFIG_BAR fi which would require the more complex dep_if CONFIG_FOO=y or CONFIG_FOO=m tristate 'Bar' CONFIG_BAR dep_fi (Not to mention the possibility that such instances are buggy and should have been a dep_tristate in the first place.) My primitives are all set to *not* ignore empty dependency values, if and when we can verify that the corpus is ready for that change. The mechanism is also there (come The Day) to change Oh no, the dreaded flag day. Heh. No, a flag day is where BIGNUM things have to be patched at once because there's no migration path. In this case there *is* a migration path, so the only things that break on The Day are things the gcml2 checker (and a grep through the makefiles for suspicious things like 'ifdef') has warned us about but we didn't bother to fix. 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
Peter Samuelson wrote: There are lots of instances of things like if [ $CONFIG_FOO = y -o $CONFIG_FOO = m ]; then dep_tristate 'Bar' CONFIG_BAR $CONFIG_FOO ... fi which can be replaced by dep_if CONFIG_FOO tristate 'Bar' CONFIG_BAR ... dep_fi Yes, this is a common case. but few, if any, instances of if [ $CONFIG_FOO = y -o $CONFIG_FOO = m ]; then tristate 'Bar' CONFIG_BAR fi which would require the more complex dep_if CONFIG_FOO=y or CONFIG_FOO=m tristate 'Bar' CONFIG_BAR dep_fi There are other ways to use if statements not covered by these two cases, for example a couple of minutes of manual scanning reveals... int ' default tagged command queue depth' CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS 8 if [ $CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS = 0 ]; then bool ' not allow targets to disconnect' CONFIG_SCSI_NCR53C8XX_NO_DISCONNECT fi ...and... if [ $CONFIG_IA64_HP_SIM = n ]; then define_bool CONFIG_ACPI y define_bool CONFIG_ACPI_EFI y define_bool CONFIG_ACPI_INTERPRETER y define_bool CONFIG_ACPI_KERNEL_CONFIG y fi ...and... bool 'Support for hot-pluggable devices' CONFIG_HOTPLUG if [ $CONFIG_HOTPLUG = y ]; then source drivers/pcmcia/Config.in else define_bool CONFIG_PCMCIA n fi How are you going to deal with these? (Not to mention the possibility that such instances are buggy and should have been a dep_tristate in the first place.) Agreed. Oh no, the dreaded flag day. Heh. No, a flag day is where BIGNUM things have to be patched at once because there's no migration path. In this case there *is* a migration path, so the only things that break on The Day are things the gcml2 checker (and a grep through the makefiles for suspicious things like 'ifdef') has warned us about but we didn't bother to fix. Ok, so not The Day but The Several Weeks During Which Things Mostly Still Work. BTW the gcml2 checker isn't checking for this kind of bug, although there's no reason it couldn't. 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: My current implementation of if_dep is *not*, as previously theorised, a drop-in two-way replacement for adding dependencies to the end of dep_* statements. I currently have it short-circuiting, so statements are in effect *not* executing in the 'n' case (or the 'm' case, for bool / dep_bool). In other words, my implementation matches current 'if [ ]' behavior, and this was on purpose. I suppose this should be made clearer in the documentation. Ok, great. I think a better solution would be to provide separate iflike statements,[...] I think that is overengineering. Sure. I was just saying that if we want a conditional statement with combined value+visibility semantics, it should be separate from the one that really matters, i.e. that which matches the old if semantics. (This works because I currently specify that the = operator treats '' as 'n'. I suppose this feature is worth debating, but I think it is useful.) Given that the makefiles treat n and as separate values with the same interpretation, i.e. don't build this, it would be more intuitive to have the config system behave similarly as far as is possible. 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
Kai Germaschewski wrote: On Thu, 15 Aug 2002, Peter Samuelson wrote: The more I think about it, the more I think the default if_dep should do the m-restricting thing. That way: dep_bool FOO1 BAR BAZ dep_mbool FOO2 BAR BAZ dep_tristate FOO3 BAR BAZ is exactly equivalent to if_dep BAR BAZ bool FOO1 mbool FOO2 tristate FOO3 fi_dep Of course, that requires the invention of 'mbool'. But I do believe it covers most if not all common cases. I guess in this case, though, it's still an open question whether 'define_bool' should be immune from the M effect (like 'mbool') or not. Seeing it from that point of view, it may actually turn into something which can agree with much more easily. Maybe it actually suffices to declare if_dep, fi_dep as virtually adds the listed arguments to each statement in the enclosed region. Maybe there would be a better name for that, then if_dep, OTOH using if_dep makes it quite clear what else_dep does. Ok, we need to be a little bit careful about semantics here, or there is going to be issues converting the existing corpus. Currently the if syntax and dependencies are not the same thing; the if condition is purely a visibility limit, and deps are both value and visibility limits. This means that if [ $CONFIG_FOO = y ]; then bool '...' CONFIG_BAR fi is not semantically identical to dep_bool '...' CONFIG_BAR $CONFIG_FOO (even ignoring the issue) because in the second case CONFIG_FOO=n forces CONFIG_BAR=n whereas in the first case it makes no difference to the value of CONFIG_BAR, so CONFIG_BAR will retain the value from previous definitions or defconfig. The proposed if_dep (or dep_if) acts as both a visibility and a value limit. So if_dep CONFIG_BAZ bool '...' CONFIG_QUUX fi_dep is semantically equivalent to if [ $CONFIG_BAZ = y -o $CONFIG_BAZ = m ]; then dep_mbool '...' CONFIG_QUUX $CONFIG_BAZ else define_bool CONFIG_QUUX n fi There's nothing wrong with this, in fact it's probably a very handy construct. But it's not a new syntax for if, it's a totally new construct with new semantics. Furthermore, you're proposing changes to the existing behaviour of existing statements like bool. In fact, at this point you're talking about changing the language in possibly incompatible ways, not just extending it to regularise semantics. I think we should focus more on first fixing problems with the existing corpus which can be fixed without changing syntax, then starting to think about language redesign for the 2.7 timeframe. [...]I didn't look into like choice statements, but I'd hope it's possible to add dependencies to them, too, for consistency. Adding a tristate value limit to int or hex makes no sense, nor to choice. You'd have to define the semantics as if_dep affects the visibility of all statements and the values of bools and tristates only. OTOH, one of the problems I can see already is that bool '...' CONFIG_FOO if [ $CONFIG_FOO = y ]; then bool '...' CONFIG_BAR [...] else define_bool CONFIG_BAR y fi doesn't translate well. Or all the cases where there are further ifs inside the else. (Hacks I can see would be: bool '...' CONFIG_FOO if_dep CONFIG_FOO bool 'not ...' CONFIG_NOT_BAR [...] fi_dep define_bool CONFIG_BAR !CONFIG_NOT_BAR Blech. bool '...' CONFIG_FOO if_dep CONFIG_FOO bool '...' CONFIG_FOO_BAR [...] fi_dep define_bool CONFIG_BAR CONFIG_FOO_BAR or !CONFIG_FOO I think a better solution would be to provide separate iflike statements, one which is a pure visibility limit like the old if but with the syntax cleaner and the behaviour with regularised; the other which does both visibility limit and a value limit on dep_bools dep_tristates (but those only, the existing bool tristate remain unchanged). If you look at the CML2 rulebase you will see constructs equivalent to both of these in use. 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: [Kai Germaschewski] I didn't look into like choice statements, but I'd hope it's possible to add dependencies to them, too, for consistency. I agree. Actually, if we're changing 'choice' anyway, it should be redesigned. Status quo takes three arguments: choice 'prompt string' 'choice-text-1 CONFIG_CHOICE1 choice-text-2 CONFIG_CHOICE2' 'choice-text-default' This is bad because it pretty much requires multi-line strings, and because the choice texts cannot have spaces in them. In my opinion it should take a variable number of args: choice 'prompt string' 'choice text 1' CONFIG_CHOICE1 'choice text 2' CONFIG_CHOICE2 CONFIG_CHOICE_DEFAULT This has already been invented, it's called nchoice, it's been documented in config-language.txt for some time, and I have working patches to implement it in all three bundled parsers. I suppose you could then extend it with dependencies by putting those at the end. That makes for minor parsing problems, since you have to detect which arguments are which - basically I guess you look for two CONFIG_* in a row. The problem is that nchoice really only gives you spaces in sub-prompts; is not expressive enough to cleanly handle some of the cases in the existing corpus. For example, # arch/ia64/config.in if [ $CONFIG_ITANIUM = y ]; then choice 'Kernel page size' \ 4KBCONFIG_IA64_PAGE_SIZE_4KB \ 8KBCONFIG_IA64_PAGE_SIZE_8KB \ 16KB CONFIG_IA64_PAGE_SIZE_16KB 16KB else choice 'Kernel page size' \ 4KBCONFIG_IA64_PAGE_SIZE_4KB \ 8KBCONFIG_IA64_PAGE_SIZE_8KB \ 16KB CONFIG_IA64_PAGE_SIZE_16KB \ 64KB CONFIG_IA64_PAGE_SIZE_64KB 16KB fi What this is trying to do is make the 64KB entry visible only when CONFIG_ITANIUM=n, and the hack is to provide two separate nearly-identical choice statements. This works OK in config menuconfig but looks down- right strange in xconfig. CML2 handled this by admitting that a choice is really a funny kind of menu, and the parts of a choice are really bools which have an extra exclusivity semantic attached. So visibility conditions could be set on individual choice items, because they were menu nodes just like bools. If you wanted to add the ability to express this in CML1, you would need a completely different syntax for choices, say something like this: menuchoice next_comment comment 'Kernel page size' choiceitem '4KB' CONFIG_IA64_PAGE_SIZE_4KB choiceitem '8KB' CONFIG_IA64_PAGE_SIZE_8KB choiceitem '16KB' CONFIG_IA64_PAGE_SIZE_16KB default if [ $CONFIG_ITANIUM != y ]; then choiceitem '64KB' CONFIG_IA64_PAGE_SIZE_64KB fi endmenuchoice i.e. menuchoice is a menu which takes only choiceitem children, and choiceitem is just like a bool except it has an optional extra argument to indicate it's the default item. I already rejected trying to do any sort of grouping - mostly because the shell parsers would choke on ( ) and nothing else looks as nice - so, since there is no way to group things, the precedence table needs to be as simple and clear as possible. I think my current proposal fits the bill. Yes, grouping is Too Hard with shell parsers. According to MEC, Linus once said, There are no default values, only default answers to questions. If a question is never asked, the value is never set. This property is used in 'make oldconfig', for one, although your proposed change wouldn't directly affect oldconfig. I'd really rather not change this property, it's actually quite useful. ESR ran into trouble when he made and n indistinguishable in the .config file, and then tried to get CML2 to work with Giacomo Catenazzi's autoconfigurator. 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: My main goal is to make it easier to write Config.in files, by making the syntax and semantics less awkward. [...] * The current 'if' statement is really ugly and unintuitive,[...] Agreed. * Current 'if' semantics are hard to get right in many common cases.[...] Agreed. I am trying to design a replacement statement which *does* cover common cases easily, while not losing any of the flexibility we have now. The current state of my proposal gives quite a bit *more* functionality than we have now - some config files have the potential to become considerably simpler / shorter. And some have the potential to become broken. [...] I have looked through the kbuild2.5 makefiles, and there were many places where Keith deliberately enforced things that looked completely arbitrary (link order in particular) merely for the sake of having an apples-to- apples comparison. It should be pointed out that Keith's task was easier in that he had exactly *one* existing set of semantics to reproduce, we have *three*. 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
[Kai Henningsen] Incidentally, wouldn't it make sense to use dep_if instead of if_dep? Yes, probably. I'll go ahead and change it in my tree, unless anyone objects violently. 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 Banks]
Ok, we need to be a little bit careful about semantics here, or
there is going to be issues converting the existing corpus.
Agreed.
Currently the if syntax and dependencies are not the same thing;
the if condition is purely a visibility limit, and deps are both
value and visibility limits.
Good point. I considered that point and I think I have it covered in
my current patch (which still doesn't work - I was gone all weekend
and got nothing done), but I guess the *documentation* doesn't
specify.
if [ $CONFIG_FOO = y ]; then
bool '...' CONFIG_BAR
fi
is not semantically identical to
dep_bool '...' CONFIG_BAR $CONFIG_FOO
(even ignoring the issue) because in the second case CONFIG_FOO=n
forces CONFIG_BAR=n whereas in the first case it makes no difference
to the value of CONFIG_BAR, so CONFIG_BAR will retain the value from
previous definitions or defconfig.
My current implementation of if_dep is *not*, as previously theorised,
a drop-in two-way replacement for adding dependencies to the end of
dep_* statements. I currently have it short-circuiting, so statements
are in effect *not* executing in the 'n' case (or the 'm' case, for
bool / dep_bool).
In other words, my implementation matches current 'if [ ]' behavior,
and this was on purpose. I suppose this should be made clearer in the
documentation.
if_dep CONFIG_BAZ
bool '...' CONFIG_QUUX
fi_dep
is semantically equivalent to
if [ $CONFIG_BAZ = y -o $CONFIG_BAZ = m ]; then
dep_mbool '...' CONFIG_QUUX $CONFIG_BAZ
else
define_bool CONFIG_QUUX n
fi
No, at least not in my implementation. Like I said, my docs might be
unclear on this point.
I think we should focus more on first fixing problems with the
existing corpus which can be fixed without changing syntax, then
starting to think about language redesign for the 2.7 timeframe.
Agreed.
Adding a tristate value limit to int or hex makes no sense, nor
to choice. You'd have to define the semantics as if_dep affects
the visibility of all statements and the values of bools and
tristates only.
That's the plan, yes.
I think a better solution would be to provide separate iflike
statements, one which is a pure visibility limit like the old if
but with the syntax cleaner and the behaviour with regularised;
the other which does both visibility limit and a value limit on
dep_bools dep_tristates (but those only, the existing bool
tristate remain unchanged).
I think that is overengineering. If you really don't want value
limits, you use 'if_dep !CONFIG_FOO=n' which, in the case of
CONFIG_FOO={y,m}, does not restrict the block.
(This works because I currently specify that the = operator treats ''
as 'n'. I suppose this feature is worth debating, but I think it is
useful.)
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
[EMAIL PROTECTED] (Greg Banks) wrote on 16.08.02 in [EMAIL PROTECTED]: No specific cases, but 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 Incidentally, wouldn't it make sense to use dep_if instead of if_dep? MfG 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
Re: [kbuild-devel] RFC: kernel config: new dependency syntax
Hi, Peter Samuelson wrote: +If the dependency yields m, the first block is executed and the +second skipped, just as with y, but with one crucial difference: the +output for certain verbs is restricted. bool and dep_bool +statements are suppressed entirely; tristate and dep_tristate are +restricted to the two values m and n. The valid values for other +verbs such as define_bool, dep_mbool and hex are not restricted. Hmm, I should have read the description, instead of the confusing table. The more formal description I just sent should match this. Anyway, I don't know if it's really that a good idea to introduce tristate logic into if statements like this. I suspect it will confuse a lot more people. Something like: if_dep dep stmt1 else_dep stmt2 fi_dep could be transformed into stmt1 dep stmt2 dep!=n Is that really intuitive? 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] RFC: kernel config: new dependency syntax
Hi,
Peter Samuelson wrote:
+If you think in terms of Boolean algebra, most of the above rules make
+sense if you think of each primitive value (y, m and n) as two
+bits: y=11, m=01, n=00. Adjacent words are implicitly ANDed
+together, and the or statement, with lower precedence, performs an
+OR between lists of words. The ! operator does not quite fit this
+explanation, because !m = m, but that was specified for practical
+reasons, to cover a common case in kernel configuration.
Simply define y=2, m=1, n=0, then you can define:
x y == min(x, y)
x || y == max(x, y)
!x == 2-x
As soon as you have to deal with more complex expressions or even
expression transformations, that will make a lot of sense. :)
+|Value of the if_dep dependency line
+ Statements in |(nested restrictions are cumulative)
+ the blocks| y | n |m
+ --+--+--+---
+ bool, | | | suppressed in
+ dep_bool | | | both blocks
+| unrestricted | suppressed |
+ --+ in if_dep| in if_dep+---
+ tristate, | block, | block, | restricted to {m,n} in
+ dep_tristate | suppressed | unrestricted | if_dep block, suppressed
+| in else_dep | in else_dep | in else_dep block
+ --+ block| block+---
+ all other | | | unrestricted in if_dep
+ verbs | | | block, suppressed in
+| | | else_dep block
+
The last coloumn makes no sense. if requires a boolean value, so you
have to convert the tristate value. This means if_dep e.g. becomes if
(dep) != n and else_dep if (dep) == n and to the dependency list you
had to add dep and !dep respectively.
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] RFC: kernel config: new dependency syntax
On Wed, 14 Aug 2002, Peter Samuelson wrote: I've reused the syntax for a dependency line (the tail end of a dep_bool / dep_mbool / dep_tristate), like so: if_dep idependency line/i ... endif 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. * !CONFIG_FOO negates sense: !y==n, !n==y, !==y, !m==m. The last !m==m is due to Roman's observation that it is useful to exclude two things from both being Y while allowing them to both be M. * '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 * 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 Hmmh, personally I don't like all these logical operations on tristates, since they are not intuitive (at least for me). 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. 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. 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 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. 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. Just my opinion, of course ;) --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
Re: [kbuild-devel] RFC: kernel config: new dependency syntax
On Thu, 15 Aug 2002, Peter Samuelson wrote: The more I think about it, the more I think the default if_dep should do the m-restricting thing. That way: dep_bool FOO1 BAR BAZ dep_mbool FOO2 BAR BAZ dep_tristate FOO3 BAR BAZ is exactly equivalent to if_dep BAR BAZ bool FOO1 mbool FOO2 tristate FOO3 fi_dep Of course, that requires the invention of 'mbool'. But I do believe it covers most if not all common cases. I guess in this case, though, it's still an open question whether 'define_bool' should be immune from the M effect (like 'mbool') or not. Seeing it from that point of view, it may actually turn into something which can agree with much more easily. Maybe it actually suffices to declare if_dep, fi_dep as virtually adds the listed arguments to each statement in the enclosed region. Maybe there would be a better name for that, then if_dep, OTOH using if_dep makes it quite clear what else_dep does. Then, there would be some more steps, which could be easily done: Make every statement accepts dependencies (and depreciate the dep_ prefixes, since they become unnecessary). There really isn't any reason for the difference between bool and dep_bool right now, it only leads to confusion and mistakes. I didn't look into like choice statements, but I'd hope it's possible to add dependencies to them, too, for consistency. Extend the normal dep_* dependencies (now just called *) to accept the same kind of dep lines as if_dep, i.e. !, =[ymn], !=[ymn], 'or', 'and'. Also, when doing that conversion, I think it may be worthwhile to get rid of the distinction between mbool and bool by something like, changing dep_mbool 'CAPI2.0 filesystem support' CONFIG_ISDN_CAPI_CAPIFS $CONFIG_ISDN_CAPI_CAPI20 to bool 'CAPI2.0 filesystem support' CONFIG_ISDN_CAPI_CAPIFS' CONFIG_ISDN_CAPI!=n and dep_bool ' AVM A1 (Fritz)' CONFIG_HISAX_AVM_A1 $CONFIG_ISA to bool ' AVM A1 (Fritz)' CONFIG_HISAX_AVM_A1 CONFIG_ISA=y I think a sensible default would be m - y in this case (like mbool), which would allow to handle 95% of the cases with just bool 'CAPI2.0 filesystem support' CONFIG_ISDN_CAPI_CAPIFS' CONFIG_ISDN_CAPI bool ' AVM A1 (Fritz)' CONFIG_HISAX_AVM_A1 CONFIG_ISA (both cases are equivalent to the above, CONFIG_ISA is a bool) If the real old dep_bool is needed, it can be written as CONFIG_FOO=y, in most cases CONFIG_FOO!=n = CONFIG_FOO will be what's needed. I'd be interested to see if these statements are actually sufficient to express all we've got today. A nice side effect of the above definition of if_dep would be that bool '...' CONFIG_FOO if [ $CONFIG_FOO = y ]; then bool '...' CONFIG_BAR [...] else define_bool CONFIG_BAR n fi can turn into just bool '...' CONFIG_FOO if_dep CONFIG_FOO bool '...' CONFIG_BAR [...] fi_dep (The CONFIG_FOO=n case would still run through the statements included by if_dep / fi_dep, automatically setting all vars to 'n', since one of their deps is 'n') OTOH, one of the problems I can see already is that bool '...' CONFIG_FOO if [ $CONFIG_FOO = y ]; then bool '...' CONFIG_BAR [...] else define_bool CONFIG_BAR y fi doesn't translate well. (Hacks I can see would be: bool '...' CONFIG_FOO if_dep CONFIG_FOO bool 'not ...' CONFIG_NOT_BAR [...] fi_dep define_bool CONFIG_BAR !CONFIG_NOT_BAR or bool '...' CONFIG_FOO if_dep CONFIG_FOO bool '...' CONFIG_FOO_BAR [...] fi_dep define_bool CONFIG_BAR CONFIG_FOO_BAR or !CONFIG_FOO both not particularly nice, but if there's only like one or two cases like this in the current config.in's, it may be acceptable) Oh well, I think the only way to find out if all that is really a good idea is to try, convert some config.in's and look at the result. --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
Re: [kbuild-devel] RFC: kernel config: new dependency syntax
[Kai Germaschewski] Seeing it from that point of view, it may actually turn into something which can agree with much more easily. Great! I've been hoping for your support - not only because I respect your judgment, but also because Linus takes patches from you. (: Maybe it actually suffices to declare if_dep, fi_dep as virtually adds the listed arguments to each statement in the enclosed region. Maybe there would be a better name for that, then if_dep, OTOH using if_dep makes it quite clear what else_dep does. OK.. Make every statement accepts dependencies (and depreciate the dep_ prefixes, since they become unnecessary). There really isn't any reason for the difference between bool and dep_bool right now, it only leads to confusion and mistakes. I've proposed this in the past - well, at least the part about making bool == dep_bool or dep_mbool, and tristate == dep_tristate. I was going to raise the issue again, after the if_dep debate settled down some. I didn't look into like choice statements, but I'd hope it's possible to add dependencies to them, too, for consistency. I agree. Actually, if we're changing 'choice' anyway, it should be redesigned. Status quo takes three arguments: choice 'prompt string' 'choice-text-1 CONFIG_CHOICE1 choice-text-2 CONFIG_CHOICE2' 'choice-text-default' This is bad because it pretty much requires multi-line strings, and because the choice texts cannot have spaces in them. In my opinion it should take a variable number of args: choice 'prompt string' 'choice text 1' CONFIG_CHOICE1 'choice text 2' CONFIG_CHOICE2 CONFIG_CHOICE_DEFAULT I suppose you could then extend it with dependencies by putting those at the end. That makes for minor parsing problems, since you have to detect which arguments are which - basically I guess you look for two CONFIG_* in a row. Alternatively, we could make the parsing job a little less fragile by using an explicit keyword like 'dep': choice 'prompt' 'text 1' CONFIG_1 'text 2' CONFIG_2 'text 3' CONFIG_3 CONFIG_1 dep CONFIG_ISA !CONFIG_ARM Translation: CONFIG_1 is the default, but the prompt is suppressed if CONFIG_ISA is unset, or if CONFIG_ARM is set. Eh? Extend the normal dep_* dependencies (now just called *) to accept the same kind of dep lines as if_dep, i.e. !, =[ymn], !=[ymn], 'or', 'and'. Already in my patches. Actually, I don't have an 'and' (Greg asked about this too), for two reasons. First, adjacent words are implicitly ANDed together anyway, so there's no need. Second, since OR takes low precedence and the implicit AND takes high precedence, having an explicit 'and' keyword would generate confusion about its precedence with regards to 'or'. I already rejected trying to do any sort of grouping - mostly because the shell parsers would choke on ( ) and nothing else looks as nice - so, since there is no way to group things, the precedence table needs to be as simple and clear as possible. I think my current proposal fits the bill. Also, when doing that conversion, I think it may be worthwhile to get rid of the distinction between mbool and bool by something like, changing dep_mbool 'CAPI2.0 filesystem support' CONFIG_ISDN_CAPI_CAPIFS $CONFIG_ISDN_CAPI_CAPI20 to bool 'CAPI2.0 filesystem support' CONFIG_ISDN_CAPI_CAPIFS' CONFIG_ISDN_CAPI!=n I think a sensible default would be m - y in this case (like mbool) That's the current default for if_dep already. I do not know if it is worthwhile to add a != operator to complement the = operator, but perhaps it is, if only because people will expect it. I'll go ahead and add it to my Menuconfig patch, at least for now. It should be noted that in many cases, this whole distinction is unimportant, because the guard symbol (for example CONFIG_ISA) is already boolean. I'd be interested to see if these statements are actually sufficient to express all we've got today. [...] Oh well, I think the only way to find out if all that is really a good idea is to try, convert some config.in's and look at the result. Right. I'll try to find the time to convert a few large Config.in / config.in files today, and post a patch (along with my current version of Menuconfig). Speaking of which - would it help anyone evaluate this stuff if I produced a patched Configure to complement the patched Menuconfig? I haven't been hacking on Configure, because for my purposes, stuff is easier to test with Menuconfig. (I added a line to init/Config.in that does source test.in, so I can easily put tests in $(TOPDIR)/test.in. Works great.) (The CONFIG_FOO=n case would still run through the statements included by if_dep / fi_dep, automatically setting all vars to 'n', since one of their deps is 'n') Reasonable people can disagree on this one. '' today means the user has never seen the question, so you would be changing existing semantics. I for one am fine with that, but others will probably argue for the status quo. According to MEC,
Re: [kbuild-devel] RFC: kernel config: new dependency syntax
Hi, On Fri, 16 Aug 2002, Kai Germaschewski wrote: Oh well, I think the only way to find out if all that is really a good idea is to try, convert some config.in's and look at the result. I really hate to spoil the fun, but could someone explain to me, why this is necessary? What problems does that fix? The only reason I've seen so far is to make the generation of (EXPERIMENTAL) possible. Is this really that important to risk new problems? 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] RFC: kernel config: new dependency syntax
[Roman Zippel] I really hate to spoil the fun (: but could someone explain to me, why this is necessary? What problems does that fix? It's not necessary, technically - it doesn't directly fix any bugs. It falls under cleanup, and as such, it is supposed to make bugs harder to write and easier to spot. The problems it solves are problems of readability and awkwardness in the current [Cc]onfig.in corpus. Basically the current discussion revolves around the best way to evolve the config language to make it more suitable for its purpose. This is of course in contrast to what ESR and you have tried, which is to replace the whole thing. My main goal is to make it easier to write Config.in files, by making the syntax and semantics less awkward. Certainly one side effect is that it will be possible to do automatic (EXPERIMENTAL) and (OBSOLETE) tags, but that has never been the primary intent. * The current 'if' statement is really ugly and unintuitive, unless you are comparing it to Bourne shell syntax, in which case it is merely ugly and *somewhat* unintuitive. (It is still unintuitive because it offers only a subset of Bourne shell functionality, and that subset is arbitrarily defined.) If you use Bourne shell syntax outside the config language spec, your file may break subtly in Configure or Menuconfig, or spectacularly in xconfig (since xconfig doesn't use the shell). Since most people don't test their changes on all three parsers, they may not notice. * Current 'if' semantics are hard to get right in many common cases. For example, a guard variable may be either unset () or False (n). If you want something to depend on the guard variable, you have to cover both cases with AND or OR. Many people do not think to do this. I am trying to design a replacement statement which *does* cover common cases easily, while not losing any of the flexibility we have now. The current state of my proposal gives quite a bit *more* functionality than we have now - some config files have the potential to become considerably simpler / shorter. * By having *one* standard syntax for dependency declarations, the whole language spec is more consistent and, incidentally, easier to write a parser for. (The fact that *human* parsing is easier as well is a related but separate advantage.) None of that answers your real question: why not use either CML2 or your work? Answer: evolution, not revolution. You say you have tried hard to keep the existing rulebase functionally identical (something Eric, of course, did not do). Fine, but so did Keith Owens when he wrote kbuild 2.5, and look where that got him. I have looked through the kbuild2.5 makefiles, and there were many places where Keith deliberately enforced things that looked completely arbitrary (link order in particular) merely for the sake of having an apples-to- apples comparison. So what did Linus do? He refused to take Keith's patches directly, but instead accepted Kai's incremental fixups to the current build system, which is nothing like Keith's system. Kai, in turn, made so many tweaks to the current system that it now resembles - in functionality if not in implementation - kbuild2.5. (Yes, the current build system is missing some features, but considering that there have been no radical changes, it's pretty impressive what Kai has managed to wring out of it.) I'm taking pretty much the same approach: removing warts from the current config system, one by one, to see how clean it can get. Perhaps eventually someone will be able to merge in a completely different system, but if so, as Greg has said, what we are doing now will lay the ground-work for such a change, by removing a lot of kludges from the rulebase. The only reason I've seen so far is to make the generation of (EXPERIMENTAL) possible. Is this really that important to risk new problems? I happen to think the risk of new problems is relatively low. My experience with Menuconfig so far is that the types of features I am adding are relatively straightforward, and it's surprisingly easy to verify that things are all working correctly. I suppose xconfig will be the usual nightmare - perhaps Andrzej (the de facto xconfig maintainer) will help out when the time comes - but Configure and Menuconfig have presented no major problems so far. There *is* the risk of adding bugs when changing the rulebase, but those will be isolated to individual rule files, and should be easy to debug if and when they happen. Of course, Menuconfig is probably the easiest of the three, since it explicitly requires bash (Configure, OTOH, works with any /bin/sh), so I don't have to worry much about shell compatibility. I guess it wouldn't hurt to install bash 1.14 somewhere so I can make sure things will work on Red Hat 6.0. An old bash bug bit me once before, in Linux 2.2.19pre Peter --- This sf.net email is
Re: [kbuild-devel] RFC: kernel config: new dependency syntax
Hi, On Fri, 16 Aug 2002, Peter Samuelson wrote: Basically the current discussion revolves around the best way to evolve the config language to make it more suitable for its purpose. This is of course in contrast to what ESR and you have tried, which is to replace the whole thing. I haven't given up yet. :) * The current 'if' statement is really ugly and unintuitive, Is that problem really that big? I think most kernel hackers can deal with that. Of course this needs fixing, but there are other more important problems. Actually this one of the simple problems my converter can solve automatically. * Current 'if' semantics are hard to get right in many common cases. For example, a guard variable may be either unset () or False (n). If you want something to depend on the guard variable, you have to cover both cases with AND or OR. Many people do not think to do this. Many people don't have to think about this, because most dependencies are quite simple. (This problem also becomes irrelevant with the new parser.) None of that answers your real question: why not use either CML2 or your work? Answer: evolution, not revolution. You say you have tried hard to keep the existing rulebase functionally identical (something Eric, of course, did not do). Fine, but so did Keith Owens when he wrote kbuild 2.5, and look where that got him. It's not really the same. CML2 and kbuild 2.5 both have the same problem - the fix all problems at once + a little bit more syndrome. Kai instead concentrated on the most important problem - correct dependencies. Most of the surgery was concentrated on Rules.make and the changes to the Makefiles were not only cleanups, but helped to fix the main problem. What is now the main problem with the config system? The shell based dependency syntax? It's an annoying problem, but not really that serious. The biggest problem are still two completely different parsers, which limit the language syntax. To solve this problem we need to drop one or both parsers. The shell parsers are the cause of the language limitations, which force us to keep the syntax imperative and makes it difficult to add new information. Nobody wants to touch xconfig. So the only solution I see is to drop both parsers. You can evolutionize as much as you want, but it doesn't help to solve the main problem. On the other hand as soon as the main problem is solved, lots of the small problems can be solved for free. I'm taking pretty much the same approach: removing warts from the current config system, one by one, to see how clean it can get. Perhaps eventually someone will be able to merge in a completely different system, but if so, as Greg has said, what we are doing now will lay the ground-work for such a change, by removing a lot of kludges from the rulebase. Try to make a list of all the problems, try to prioritize them and estimate the needed changes to rulebase and parsers. Now try to minimize the amount of work needed to solve all the problems. You currently ignore the xconfig problem, which seem to make most of the problems easily solvable, but we possibly end up with a broken X interface. The new parser with the new frontends is the largest amount of the work, which needs to be done anyway and once it's done, it will solve a lot of the small problems automatically. I don't think that making multiple large syntax changes is a good idea. Learning a new syntax is already annoying, but having to do it multiple times will really annoy a lot of people. Making some small controlled extensions or small rulebase fixes are not the problem, but you should really try to avoid changes which require massive changes to all config files. 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] RFC: kernel config: new dependency syntax
[I wrote] I've come up with syntax I think I'm happy with. Thank you one and all for all the discussion and suggestions for improvement on my proposals. I've incorporated a lot of feedback. I know I promised to try and come up with a working prototype including some Config.in files, but some of the Menuconfig bits were harder than they looked, and I ran out of time tonight - I'm about to leave town for a couple of days. My Menuconfig currently doesn't work, and I haven't converted any Config.in files yet. Meanwhile, here is the documentation portion. Critiques are more than welcome, both for the proposal and for its documentation.. Peter --- 2.5.31/Documentation/kbuild/config-language.txt 2002-06-09 00:29:17.0 -0500 +++ 2.5.31w/Documentation/kbuild/config-language.txt2002-08-16 21:18:16.0 +-0500 @@ -84,8 +84,10 @@ 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 /dep/ is a dependency list. Syntactically, it is zero or more +/word/s separated by whitespace. When evaluated, a /dep/ is +reduced to a single character y, m or n. See the following +section for details. An /expr/ is a bash-like expression using the operators '=', '!=', '-a', '-o', and '!'. @@ -116,12 +118,12 @@ Dependent statements: -dep_bool/prompt/ /symbol/ /dep/ ... -dep_mbool /prompt/ /symbol/ /dep/ ... -dep_hex /prompt/ /symbol/ /word/ /dep/ ... -dep_int /prompt/ /symbol/ /word/ /dep/ ... -dep_string /prompt/ /symbol/ /word/ /dep/ ... -dep_tristate/prompt/ /symbol/ /dep/ ... +dep_bool/prompt/ /symbol/ /dep/ +dep_mbool /prompt/ /symbol/ /dep/ +dep_hex /prompt/ /symbol/ /word/ /dep/ +dep_int /prompt/ /symbol/ /word/ /dep/ +dep_string /prompt/ /symbol/ /word/ /dep/ +dep_tristate/prompt/ /symbol/ /dep/ Unset statement: @@ -132,7 +134,22 @@ choice /prompt/ /word/ /word/ nchoice /prompt/ /symbol/ /prompt/ /symbol/ ... -If statements: +New-style if blocks: + +if_dep /dep/ + /statement/ + ... +fi_dep + +if_dep /dep/ + /statement/ + ... +else_dep + /statement/ + ... +fi_dep + +Old-style if blocks (deprecated): if [ /expr/ ] ; then /statement/ @@ -161,6 +178,69 @@ +=== Dependency lists + +A dependency list evaluates to a single character y, m or n. +Individual words in the list can include: + +The word or divides a list into two sub-lists, one on either +side of the or. The sub-lists are evaluated independently and +then combined, as described below. + +A /symbol/ is expanded to the current value of the symbol, or the +empty string if the symbol is unset. In the latter case, if +/symbol/ appears in a word by itself, the word is ignored. This +is for backward compatibility and may change in the future. + +If a /symbol/ has a $ prefix, that prefix is ignored, for +backward compatibility. This may become a syntax error in the +future. + +A word with a suffix of =X, where X is a quoted or unquoted +string, expands to y if the rest of the word evaluates to X, or +n otherwise. + +A word prefixed by ! expands to a transformation of the word: +!y becomes n; !n or ! become y; !m becomes m. The +! prefix is expanded only after expansion of /symbol/s and the += suffix. + +Once each word is expanded as described above, it should have a value +of y, m or n, or the empty value , which is discarded. If the +dependency list has multiple words, the words are reduced to a single +word as follows: + +If any word is n, the value of the list becomes n. + +Otherwise, if any word is m, the value of the list becomes m. + +Otherwise, the value of the list becomes y. + +If there are multiple sub-lists separated by or words, each sub-list +is reduced to a single word as described above, then they are combined +as follows: + + If any sub-list is y, the final result is y. + + Otherwise, if any sub-list is m, the final result is m. + + Otherwise, if all sub-lists are n, the final result is n. + +Finally, an empty /dep/ evaluates to y. + +If you think in terms of Boolean algebra, most of the above rules make +sense if you think of each primitive value (y, m and n) as two +bits: y=11, m=01, n=00. Adjacent words are implicitly ANDed +together, and the or statement, with lower precedence, performs an +OR between lists of words. The ! operator does not quite fit this +explanation, because !m = m, but that was specified for practical +reasons, to cover a common
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] 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] RFC: kernel config: new dependency syntax
Peter Samuelson wrote: I've come up with syntax I think I'm happy with. It supports most of the current [ ] based if statement semantics, can be implemented in shell, and (most importantly for me) drops those $ signs. This lays the groundwork for stuff like better error checking and auto (EXPERIMENTAL) tags. I've reused the syntax for a dependency line (the tail end of a dep_bool / dep_mbool / dep_tristate), like so: if_dep idependency line/i ... endif If the dependency line evaluates to 'm' or 'y', the body is executed. Hmm. Perhaps (I haven't completely thought this through) by analogy with dep_bool/dep_mbool, you would want two new if statements which differ in the way they treat 'm'? If the conditional syntax is the same people may expect that. Also you will want to define the behaviour when the line evaluates to 0. ./arch/sparc64/config.in:180:if [ $CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS = 0 ]; then ./drivers/scsi/Config.in:166: if [ $CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS = 0 ]; then [*] 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. * '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 How about an 'and' operator too, which is redundant but more readable. --- 2.5.31/scripts/Menuconfig 2002-06-09 00:27:32.0 -0500 +++ 2.5.31w/scripts/Menuconfig 2002-08-14 21:00:27.0 -0500 @@ -112,6 +115,67 @@ eval info=\$INFO_$1 } + +# Reduce a dependency line down to a single char [ymn]. +# Terms are implicitly ANDed together: 'y m' = 'm y' = m, '... n' = 'n ...' = n Also 'y y' = y I'll look at the rest when there's an else. 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
