[lkml]   [1998]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: xconfig lossage: summary and suggestions (long)
On Tue, 17 Feb 1998, Regis Duchesne wrote:
> I have begun to do it. Here is how for me Config files should be for the
> moment:
[warning: The following quotes are very much out of order...]
> I.1 Test variables
> They can have the value "n", "m", "y".
> They can be used in test conditions.
> I.2 Data variables
> They can have integer, hexadecimal, or string values.
> They can _not_ be used in test conditions.
Any piticular reason why not? I would define three basic types: integer,
string, and undefined. Booleans (and tri-states) are synonmous with
strings. All comperiasons involving undefined varibles are false (breaking
!(a!=b) being equivelent to a=b, but that is fairly normal). Between their
first mention (including in a dependincy) and when they are assigned a
value, all varibles are undefined.

They can both be validly used as dependinces.

> I.1.1.1.a To "n", "y"
> bool <label> <test_variable>
> Note: The following construction is wrong:
> bool <label> <test_variable> <value>
Any clue what they mean here? If this was ment to be parsed as defaulting
to <value>, I'm not shure it's a bad feature (indeed, I think it's a good
feature), but it isn't one that's supported by the current synthax. Such
usages should be hunt down and shot... See the attached patch (vs. 2.1.87).
(OK, this message is getting to long, so it is as a sepperate posting.)

> 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>]...
... otherwise, only "n" or "m" are possible. Also, all dep_tristates
(and tristates) are implicitly dependent on CONFIG_MODULES. (Also, I think
you are missing spaces in the dependancy list -- just to be pedantic.)

> II How to write a correct
> A simple configuration tool must be able to read a 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
All varibles should have a default defined by the approate defconfig before
use. If not, its value is thought to be "". (Is this correct? Flat-config
takes the value to be "n", I'm not certian of xconfig, and menuconfig takes
the value to be "". One of them is obviously wrong, but which?)

> 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/ files
> Read/write .config files, write autoconf.h file
I think that the autoconf.h writing program should remain sepperate from the
.config writer... I see no compeling reason to merge them... for one thing,
the .config file is ment to be human-readable and modifible. If we merge,
then that is in some jeporday.

> 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 files.
> > (As it is now, xconfig or menuconfig often crashes because
> > of unexpected input.)
> II.1.2 second round
> Change the syntax, that will be transparent for all back-ends, thanks to
> our parsing library.
Why are we checking that all [Cc]onfig.ins are compliant to the old standard
before upgrading all of them to the new synthax?

> 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 instead
> of [cC]
So that an old-style config file and a new-style config file can be told
apart by name was my intent, but keeping a consistant name is a Good Thing

> > 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
Then again, the includes need to be done AFTER checking if that line should
be parsed as in the current system, not before it as in C (the
pre-processor, rather).

> 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.

Huha? I'm sorry, but that made no sense to me...
Somthing like:
y/m/n 'foo' (CONFIG_A == y && CONFIG_B == y)
y/n 'foo' ((CONFIG_A || CONFIG_B) == m)

This should be interpreted as factoring out a "== m" from "(CONFIG_A
== m || CONFIG_B == m)", which neither C nor Mathematical Logic allow <G>,
but I like.

In any case, is that what you ment?

> > 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
> 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 :(

There are two current ways of handling this, I think: menuconfig thinks the
value is "" (thus, it isn't n, nor y, nor m, messing up the "really broken
sound driver" (though I'm uncertian -- perhaps it is the really broken
menuconfig).) Then again, config thinks that the value is "n".

> My library also issue warnings for name that don't begin with CONFIG_
I don't think that I like this (for the new synthax, that is)... Being able
to do varible substitution for things like MAXIRQ is nice, so I think that
not having a "CONFIG_" prefix should just meen that the varible is internal,
and shouldn't be writen out to the .config file.

> > 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.)
BAD HACK! BAD HACK! BAD HACK! (Yes, I am saying that about my own idea...
Everybody screws up now and again.)

> 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:
> n
> m CONFIG_MODULE == y && CONFIG_B == m
> y CONFIG_B == y && CONFIG_C == y
I fundementaly LIKE this idea... (Though the "CONFIG_MODULE == y" should be
impled on the m part...) However, I think we need a real-world example at
this point: how about CONFIG_BINFMT_JAVA for starters...


So this would meen that CONFIG_BINFMT_JAVA defaults to n if never perviously
defined (get rid of defconfigs), and can be set to m or y only if
EXPERMENTAL is y. Simple enough. (Note that = and == should be identinal
here -- we don't really want people setting options in the dependincy
information.) (Also note that I didn't use a CONFIG_ prefix on EXPERMENTAL,
as we don't really do code dependincies on it.)

If CONFIG_EXPERMENTAL isn't defined, then we even don't offer the option, we
simply set CONFIG_BINFMT_JAVA to n (differing from the current behivor of
not setting it). I'm not to certian how I like that. It's closer to what's
really going on, but it's also farther from what we really want
(CONFIG_BINFMT_JAVA won't show up as new if CONFIG_EXPERMENTAL is ever

How about somthing more complex: CONFIG_SB_MPU_IRQ...
!n CONFIG_SB = y

or is this nicer?

This does some more complex stuff... We mix boolean and integer types here,
use ranges, and varible substitution, all of which are fairly
straight-forward. Not quite so straight-forward is that we want to have
everything here dependant on CONFIG_SB=y -- we don't want CONFIG_SB_MPU_IRQ
defined at all if CONFIG_SB = (m || n).

Anybody see problems with this synthax? (Other then that the ! for default
looks too much like negation -- anybody with a better idea? It can't be
used as a option without messy quoting, and it shouldn't be a commonly-used
wildcard character either...)

> 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
Hmm... but what about comments that aren't really a menu-head ("MPU401 IRQ
is only required with Jazz16, SM Wave and ESS1688.")

> 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.
I like just replacing choice lists with single varibles that can take any of
a number of values, just like the above:


(no dependinces on any of these, as this file would only be looked at if
arch=ia32 anyway. The long-names of these would be in the helpfile.)

> 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 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.
No reason not to do both. I note, however, that much of the work on a
tcl/tk version is already done...

> For me, only options
> which are really new in files and have never been used (the
> variable has never been defined) should appear as new.
Rock on! How this should be done, however, is quite another problem --
having each value be a struct (to store current-value and a touched flag)
would complacate things, at least concepualy. But having real live symbols
with value "n" means converting every #ifdef CONFIG_FOO to #if CONFIG_FOO="y".

> 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 files.
> Agreed. We can work on it from now on, but we should think about
> inclusion in 2.3 kernels.
I certianly hope that 2.2 comes out before we're all done with this stuff <G>.

> 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
> (O o) I use Linux & 3Com (1135 KB/s over 10Mb/s ethernet)
> --.oOO--(_)--OOo.-----------------------------------------------------------

-=- James Mastros
Student of life, and of high school <G>

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to

 \ /
  Last update: 2005-03-22 13:41    [W:0.055 / U:0.688 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site