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 "if"like
> 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_bool"s & "dep_tristate"s (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=sourceforge1&refcode1=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=sourceforge1&refcode1=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 Mon, Aug 19, 2002 at 07:27:50PM +1000, Greg Banks wrote: > I'm not optimistic that a switch to a new language or even a new > parser for the old language will ever happen. I asked Linus specifically about the replacement of the shell based parsers. The answer were quite simple: - It should be convinient to use a new parser. - Fast compilation, no errors etc. It's doable. > In http://marc.theaimsgroup.com/?l=linux-kernel&m=101387128818052&w=2 > David Woodhouse gives an idea of what would be necessary to get a new > language+parser accepted. Can you achieve that yet? David suggest to use randomly generated configurations, but they lack one important feature. They are always valid, and a new system shall be able to deal with hand-edited .config files in the same way as oldconfig. Sam --- 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=sourceforge1&refcode1=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, On Mon, 19 Aug 2002, Greg Banks wrote: > 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 BTW with my syntax this would look like: choice prompt 'Kernel page size' default IA64_PAGE_SIZE_16KB help ... config IA64_PAGE_SIZE_4KB boolean '4KB' help ... config IA64_PAGE_SIZE_8KB boolean '8KB' help ... config IA64_PAGE_SIZE_16KB boolean '16KB' help ... config IA64_PAGE_SIZE_64KB boolean '64KB' if ITANIUM help ... endchoice You can also define multiple defaults. A config item also can have sub items. 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=sourceforge1&refcode1=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=sourceforge1&refcode1=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 "bool"s which have an extra exclusivity semantic attached. So visibility conditions could be set on individual choice items, because they were menu nodes just like "bool"s. 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=sourceforge1&refcode1=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, On Mon, 19 Aug 2002, Greg Banks wrote: > Unlike you, I'm not optimistic that a switch to a new language or even a new > parser for the old language will ever happen. It would be nice if I could get it into 2.6, but it's not a problem if it has to wait. I'm currently busy getting menuconfig working again and then I'm pretty much ready for a beta release. > In http://marc.theaimsgroup.com/?l=linux-kernel&m=101387128818052&w=2 > David Woodhouse gives an idea of what would be necessary to get a new > language+parser accepted. Can you achieve that yet? If you compare it to the xconfig output, yes. > Or you could, today, go build gcml2 from source with "make DEBUG=1" and run I looked through the list and except from real syntax errors nothing prevents an automatic conversion. I have to manually fix things like CONFIG_ALPHA_NONAME, which is first set by a choice statement and later redefined. My new parser can't deal with this, because user input is given the highest priority. 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=sourceforge1&refcode1=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 "if"s 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 "if"like 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_bool"s & "dep_tristate"s (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=sourceforge1&refcode1=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: > > The problem here is one should consider, how all these little changes will > help to solve the big problems. Do they allow to more easily fix the big > problems or have these changes to be dumped again? I believe fixing the existing rules within the existing syntax is an exercise worth doing, and that the results will carry across to whatever extended syntax/ new language/new parsers/whatever will be the long-term solution. Extending the CML1 syntax now is a fun game but a gamble. > Most of the suggestions I've seen so far fix problems, which either can be > either fixed automatically or which don't exists anymore, once we switch > to a new syntax/parser. That's the reason I ask to understand the whole > picture, so we can judge whether a change is really necessary or not. Unlike you, I'm not optimistic that a switch to a new language or even a new parser for the old language will ever happen. > I can't give you a mathematical proof, but I tried very hard to keep the > behaviour the same. Unless I made mistake the rules are almost exactly the > same. Most of the CML1 rules are usable, there are only very few cases > which need manual fixing. I can't guarantee that where won't be any > surprises, but they should be easily fixable in the new system. (Unless > ESR I don't insist that my rulebase is correct or perfect, so I'm open to > suggestion/changes. :) ) In http://marc.theaimsgroup.com/?l=linux-kernel&m=101387128818052&w=2 David Woodhouse gives an idea of what would be necessary to get a new language+parser accepted. Can you achieve that yet? > Most of these problems can actually be fixed without syntax changes. Yes, a great deal of them can be, and those should be done ASAP. > Something that can't be sanely fixed this way are recursive dependencies, > which I think are not worth fixing with the old parsers, but which are > easily fixable with the new syntax. Indeed, and those are rare corner cases. > If you want to fix logical errors in the rulebase, they will be more > easily fixable with the new tools. For the X interface I'm planning some > debug options, which e.g. allow you to see the complete dependencies of > every symbol. Or you could, today, go build gcml2 from source with "make DEBUG=1" and run cml-check --debug nodes arch/i386/config.in 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=sourceforge1&refcode1=vs3390 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] ANNOUNCE: gcml2 0.7
G'day, gcml2 is (among other things) a Linux kconfig language syntax checker. Version 0.7 is available at http://sourceforge.net/project/showfiles.php?group_id=18813&release_id=106023 and http://www.alphalink.com.au/~gnb/gcml2/download.html There's also an online summary of the warnings and errors from the syntax checker, with real examples, from http://www.alphalink.com.au/~gnb/gcml2/checker.html Here's the change log * Warnings can be individually enabled. Default set depends on whether the parser is in merge mode. API functions to enable/disable warnings by index and convert a string name to an index. * Added check for define to nonliteral expression. * More precise check for ambiguous comparison against "n" only complains for symbols which are forward-declared at the point when compared. * Made inconsistent-tag warnings more precise; doesn't emit spurious warnings about define_bool not having an (EXPERIMENTAL) tag. * More precise check for forward references and forward dependencies can tell the difference between forward and undeclared, at the cost of some storage. * Check for overlapping definitions by reducing conditions to disjunctive normal forms. * Added check for forward dependencies. * Added check for misuse of and dependency on arch-constant symbols like CONFIG_X86. * Renamed summarise-warnings.awk -> summarize.awk and installed it. * Added cml-summarize shell script, which runs summarize.awk. * Added cml-check-all shell script, based on old dochecks.sh, but now also handles running cml-summarize. * Added manpages for cml-check, cml-check-all and cml-summarize. Description of errors and warnings for the cml-check manpage is controlled in HTML and shared with the web page. * RPM package support: added spec file, rpm: target. 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=sourceforge1&refcode1=vs3390 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
