> maybe we should first
> write a formal grammar of the Config files (what can a
> Config.in file look like?) and describe the semantics.
> For example, does `define_bool' have a static interpretation,
> i.e., does it mean that the variable is a Boolean combination
> of other variables? Then it cannot be an independent configuration
> option. Or does it have a dynamic interpretation: when you get here,
> do this assignment?
It's dynamic. When in doubt, remember that the Config.in format is
nothing else than a shell script.
> Then fundamental assumptions of kconfig.tk are
> violated, and parts of xconfig have to be rewritten.
Agreed.
> Schedule:
> 1. Write a doc file that describes the semantics of the Config.in files.
MEC and I have already done some work on this.
MEC wrote:
> I agree that someone should write documentation that specifies the
> syntax and semantics of Config.in files. I will take responsibility for
> writing this file.
I have begun to do it. Here is how for me Config files should be for the
moment:
----------------------------
I Introduction
A configuration tool allows to set the value of some variables. There are
2 kinds of variables:
I.1 Test variables
They can have the value "n", "m", "y".
They can be used in test conditions.
I.1.1 Set one variable
I.1.1.1 By hand
I.1.1.1.a To "n", "y"
bool <label> <test_variable>
Note: The following construction is wrong:
bool <label> <test_variable> <value>
I.1.1.1.b To "n", "m", "y"
tristate <label> <test_variable>
I.1.1.1.c To "n", "m", but "y" only if all dependancies (which are
test_variables) are "y"
dep_tristate <label> <test_variable> <dependancy1>[<dependancyN>]...
I.1.1.2 Automatically to "y", "m", "n"
define_bool <test_variable> <value>
I.1.2 Set several variables by hand to "y", "n"
choice <label> <choice_list> <default_choice>
The <choice_list> syntax is
<choice1> <test_variable1>[ <choiceN> <test_variableN>]...
And the <default_choice> must be a _unique_ prefix of a <choiceN>.
The chosen test variable will be set to "y", and the other test variables
will be set to "n".
I.2 Data variables
They can have integer, hexadecimal, or string values.
They can _not_ be used in test conditions.
I.2.1 Set one variable by hand
int <label> <data_variable> <default value/variable> [<min_value> <max_value>]
hex <label> <data_variable> <default_value/variable>
string <label> <data_variable> <default_value/variable>
II How to write a correct Config.in
A simple configuration tool must be able to read a config.in file from its
beginning to its end. Consequently, you can _not_ use a variable before
defining it:
if [ "$CONFIG_A" = "y" ]; then
comment 'Nobody will ever see me'
fi
bool 'A option' CONFIG_A
-----------------------------------
Ok to set up a new project, here is what we should do:
I The goal
AB wrote:
> 4. Extend the parser, so that it can be the frontent for both menuconfig
> and xconfig.
. Have a unified pure C library providing services to back-ends:
Parsing/checking defconfig/config.in files
Read/write .config files, write autoconf.h file
Read the help text associated with an option
Variable handling (management of the dependancies)
. Have several drop-in replacement front-ends for
config/menuconfig/xconfig
So that Linus will be happy (make config is a C program that compiles
fast and without requiring any special library)
II The schedule
II.1 Development
A 2 round development:
II.1.1 first round
AB wrote:
> 3. Write a parser that will check all Config.in files.
> (As it is now, xconfig or menuconfig often crashes because
> of unexpected input.)
Drop-in replacement for config/menuconfig/makeconfig with the _same_
config.in syntax, but a better check of it.
I have already done this partly: evrything is parsed, but I have to handle
some special cases like in the sound driver which uses
int 'foo' CONFIG_A $CONFIG_B instead of the classical
int 'foo' CONFIG_A 13 for example.
II.1.2 second round
Change the syntax, that will be transparent for all back-ends, thanks to
our parsing library.
> 2. Write a grammar that describes their syntax.
Yes we have to do that for the new syntax.
AC wrote:
> (sparc i386) bool "has a fnord device" Y
> and make a script to write all the Config.* format files from a sane
> input format ?
I don't like that, this is like adding yet another layer. I do prefer
what MEC suggested:
> I think this is ungainly, but not terminally broken:
>
> if [ "$ARCH" = "sparc" -o "$ARCH" = "i386" ]; then
> bool "has a fnord device" Y
> fi
The idea is good. We just have to use a more adequate syntax.
JM wrote some ideas for the new syntax:
> renaming them to [foo].cfg at the same time
good idea. We should at least unify their names : always Config.in instead
of [cC]onfig.in
> Including subfiles is almost definatly good, so we need a way to include
> them... how about INCLUDE foo.cfg (that is to say the first
> non-whitespace
> word dosn't begin with a "(", and is "INCLUDE").
Agreed, we should use a C syntax the more we can. That's
include foo.cfg
and in tests too:
if CONFIG_A == y && CONFIG_B != m ...
> 1) The ablity to define complex dependincy rules
> (dependincies) option value_1/value_2/...
Agreed, this is important for dep_tristate: we could directly give the
dependancy for the "y" value (the dependancy for the "m" value is always
CONFIG_MODULE == y): that way, for classical dep_tristate, we could use:
dep_tristate 'foo' CONFIG_A CONFIG_B == y
but we could also use
dep_tristate 'foo' CONFIG_A CONFIG_B != m
in order to avoid the definition of bogus options like in the sound
driver.
> Value_1 is a possible value (y/n/m...). Also, numbers and ranges should
> be possible. Being able to say "(CONFIG_SB=y) CONFIG_SB_MPU_IRQ
> n/1-MAXIRQ" would be a win, so we need somthing like "(CONFIG_ARCH=ia32
> CONFIG_SMP=n) MAXIRQ 16" is needed
Good idea. So we really need variable substitution
> Common constructions at this point seem to be:
> 1. (CONFIG_FOO != n) CONFIG_BAR y/m/n
> 2. (CONFIG_FOO = y) CONFIG_BAR y/m/n
> (CONFIG_FOO = m) CONFIG_BAR m/n
mmm. IMHO, we should keep the if/then/else/fi syntax. It is really
powerful and humanly readable
> The first is simple... we just need to relise that any comparison
> involving an undefined varible is false. (If CONFIG_FOO is undefined,
> "CONFIG_FOO != n"
> is false, but so is "CONFIG_FOO = n".) (This shouldn't show up in
> pratice, as everything should be initialised in defconfig.)
Yes, in the current implementation of my parsing library, I solved this
problem this way: if we have a test with an undefined variable, a syntax
warning is issued, but in order to be compatible with already existing and
broken script, the value of the variable is temporarily "n" (this should
be safe). This particularly happens in the really broken sound driver :(
My library also issue warnings for name that don't begin with CONFIG_
> The second is harder to deal with, but I think this is acceptable:
> (CONFIG_FOO != n) CONFIG_BAR CONFIG_FOO/m/n (I.E. options are only
> presented once, even if they appear multiple times in the list.)
If we want to do that, the simplest is is my opinion to specify the
dependancy for each possible value: we could have something like that:
CONFIG_A
n
m CONFIG_MODULE == y && CONFIG_B == m
y CONFIG_B == y && CONFIG_C == y
> (IE the rule is that if there is only
> one option, then that option is picked without asking the user).
Of course. In my last example, the CONFIG_A would be disabled and set to
"n"
I had some other thought regarding the syntax:
I get rid of the mainmenu_title, mainmenu_option, next_comment
and comment crap and unify this in:
Menu 'my main menu'
Menu 'title2'
EndMenu
Menu 'title3'
EndMenu
EndMenu
For Choice lists, I use the same thing, but without allowing
nesting:
Choice 'my choice list' 2 <- default choice
Bool 'choice1' CONFIG_A
Bool 'choice2' CONFIG_B
EndChoice
Of course, bool could be replaced by the things we have discussed above.
Note: For the xconfig, I'm looking very hard to the GTK widget set, which
is very easy to use with C, and which is more beautiful and a lot faster
than TCL/TK. Moreover, we could use a "collapsable/expandable tree widget"
to display the structure of such a config.in file.
Of course it is currently less widely spread than TCL/TK,
but do we consider this a good reason not to use superior software? No,
otherwise we would use Windows.
Note: For the .config generation, I'm planning to add some compatible
modifications too: If a variable is disabled (I mean that the variable is
for example defined in a if statement whose condition is false), but that
variable was "y" before being disabled, I want to write it int the .config
like this
#
# Usual comment
#
CONFIG_ENABLED_OPTION=y
##CONFIG_DISABLED_OPTION=y
CONFIG_ANOTHER_ENABLED_OPTION=n
So that when the option is enabled again, its value is restored too, and
the option is not displayed as being "new". Because for the moment,
menuconfig show it as being new. But it is not new since this option was
existing in previous version of config.in files. For me, only options
which are really new in config.in files and have never been used (the
variable has never been defined) should appear as new.
II.2 Inclusion in the kernel
MEC wrote:
> This is going to take a long time. For 2.2, I think we are better
> off simply hacking the existing Config.in files.
Agreed. We can work on it from now on, but we should think about
inclusion in 2.3 kernels.
Any suggestions appreciated. Perhaps should we set-up a separated
mailing-list and a home page for this project. Although my parsing lib is
almost finished, there is still a lot of work to on back-ends.
Best regards,
Regis "HPReg" Duchesne - Engineering Student at ***** ******** *****
www http://www.via.ecp.fr/~regis/
(O o) I use Linux & 3Com (1135 KB/s over 10Mb/s ethernet)
--.oOO--(_)--OOo.-----------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu