lkml.org 
[lkml]   [1998]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subjectxconfig lossage: summary and suggestions (long)
    AB wrote:
    > What goes wrong is that tkparse.c does not understand that
    > a variable may occur in several different places.
    > (In this case: net/Config.in has
    > bool 'Kernel/User netlink socket' CONFIG_NETLINK
    > and net/ipv4/Config.in has
    > define_bool CONFIG_NETLINK y
    > .)
    Agreed. tkparse.c is broken

    > 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

    \
     
     \ /
      Last update: 2005-03-22 13:41    [W:0.038 / U:31.272 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site