Hi,
At http://www.xs4all.nl/~zippel/lc.tar.gz you can find a prototype for a
new linux configurator (see the included README for build/use
information). It has reached a point, where it's becoming usable and I
need some feedback on how/if to continue.
In the first place I wanted to address the problems which came up in
discussion about cml2. So how does it compare to cml2?
1. It's written in C (except the X interface that is in C++ because it
uses qt), so it's really fast.
2. As I convert the current cml1 configuration, it represents pretty
much the same information (and I don't have to maintain lots of new
rules).
3. It's less complex, but IMO sufficient for basic kernel configuration
and all information for a single configuration symbol is at a single
place.
The last point is the most important one and needs some more
explanation, I could have lived with the other problems, but this this
one motivated me to write this tool. I think Eric tries to solve too
many problems at once and this also caused the opposition in previous
discussions. There are basically two problems:
1. Which information is required to compile a driver into the kernel?
2. Which information is needed from/by the user to compile a kernel?
I only try to solve the first problem, Eric also tries to solve the
second problem, but the mistake he made here is to mix up these two
problems. Autoconfiguration is an important problem, but it must be kept
optional, whereas the first problem must be solved, otherwise the kernel
won't even compile. Keeping the problems separate simplifies also the
needed solutions.
Anyway, everyone can now check himself, which solution he prefers. What
I need to know now is, if and how we join both efforts. It's possible
everyone prefers now Eric's cml2 and thinks that my approach is too
simple.
BTW my configurator has a nice new feature: tristate choices. It solves
some problems IMO more elegant than cml1 or cml2. Save the following as
config.new and try yourself. :)
config MODULES
boolean "module support"
config SYS
tristate "SYS"
help
some subsystem
choice
prompt "ABC"
default A
depends SYS
#try also to disable this
optional
help
abc
config A
tristate "A"
help
a
config A1
boolean "A1"
depends A
help
a1
config B
tristate "B"
help
b
config B1
boolean "B1"
depends B
help
b1
config C
boolean "C"
help
c
config C1
boolean "C1"
depends C
help
c1
endchoice
bye, Roman
Hi,
I wrote:
> At http://www.xs4all.nl/~zippel/lc.tar.gz you can find a prototype for a
> new linux configurator (see the included README for build/use
> information). It has reached a point, where it's becoming usable and I
> need some feedback on how/if to continue.
There is a new version at http://www.xs4all.nl/~zippel/lc/lc-0.2.tar.gz,
this version also works with qt2.x.
So far I hadn't very much feedback. What's up? Is everyone suddenly
completely happy with cml2? Now is your chance to evaluate the
alternatives or does this require too much work before you can start
flaming?
bye, Roman
On 2002.03.17 Roman Zippel wrote:
>Hi,
>
>I wrote:
>
>> At http://www.xs4all.nl/~zippel/lc.tar.gz you can find a prototype for a
>> new linux configurator (see the included README for build/use
>> information). It has reached a point, where it's becoming usable and I
>> need some feedback on how/if to continue.
>
After seeing all that many tools for kernel config, I always wanted to ask
this.
There is something (as an 'external' viewer) I never understood.
Why nobody has taken the 'obvious' way ?
- Perl is much more extended that python and better? than sh for CML.
- Perl has perl-Curses (for menuconfig)
- Perl has perl-GTK (for xconfig) (so you geet rid of tcl/tk)
Reasons ?
--
J.A. Magallon # Let the source be with you...
mailto:[email protected]
Mandrake Linux release 8.2 (Bluebird) for i586
Linux werewolf 2.4.19-pre3-jam3 #1 SMP Fri Mar 15 01:16:08 CET 2002 i686
Neat.
I would appreciate somewhat more readability, though. It's not very
simple to figure out in which state an option is (Y/N/M) if it's not focused.
Maybe put the selected variant before the option name:
+ Networking options
+ Packet socket
| <M> Netlink device emulation
| <N> Network packet filtering ...
Besides, i think your selection of qt as gui platform is not making you
many friends, though greatly speeded up the development.
-alex
On Sun, Mar 17, 2002 at 02:05:18PM +0100, Roman Zippel wrote:
> Hi,
>
> I wrote:
>
> > At http://www.xs4all.nl/~zippel/lc.tar.gz you can find a prototype for a
> > new linux configurator (see the included README for build/use
> > information). It has reached a point, where it's becoming usable and I
> > need some feedback on how/if to continue.
>
> There is a new version at http://www.xs4all.nl/~zippel/lc/lc-0.2.tar.gz,
> this version also works with qt2.x.
> So far I hadn't very much feedback. What's up? Is everyone suddenly
> completely happy with cml2? Now is your chance to evaluate the
> alternatives or does this require too much work before you can start
> flaming?
>
> bye, Roman
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Hi,
Alex Riesen wrote:
> I would appreciate somewhat more readability, though. It's not very
> simple to figure out in which state an option is (Y/N/M) if it's not focused.
> Maybe put the selected variant before the option name:
> + Networking options
> + Packet socket
> | <M> Netlink device emulation
> | <N> Network packet filtering ...
Hmm, looks good, the current version has the advantage, that one sees
the available input range, but that's probably only important for
debugging.
So far I want to keep it simple, it should be just enough for people to
play with and for me to experiment with some ideas. Anything more fancy
has to wait.
> Besides, i think your selection of qt as gui platform is not making you
> many friends, though greatly speeded up the development.
"And I personally refuse to use inferior tools because of ideology." :)
It's not the first time I hear this, I'd really like to know where this
is coming from. I don't mind if someone implements the ui with another
toolkit, I'd actually be happy about this, as the ui part is more of a
burden for me, but until then I keep things simple for myself.
bye, Roman
On Tue, Mar 19, 2002 at 08:27:23PM +0100, Roman Zippel wrote:
> "And I personally refuse to use inferior tools because of ideology." :)
> It's not the first time I hear this, I'd really like to know where this
> is coming from. I don't mind if someone implements the ui with another
Ok you can remove it from your linus fortune file.
> toolkit, I'd actually be happy about this, as the ui part is more of a
> burden for me, but until then I keep things simple for myself.
Don't expect from me (and others I guess) to install the qt2 libs to
configure my kernel.
Is there a clear separation between GUI and other code ?
Do you provide a oldconfig-like functionnality ?
Christophe
> bye, Roman
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Christophe Barb? <[email protected]>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E
As every cat owner knows, nobody owns a cat.
--Ellen Perry Berkeley
Hi,
On Tue, 19 Mar 2002, christophe barb? wrote:
> Ok you can remove it from your linus fortune file.
I don't have one.
> Don't expect from me (and others I guess) to install the qt2 libs to
> configure my kernel.
I'm curious, is python+tk any better/worse?
> Is there a clear separation between GUI and other code ?
Yes, although the interface needs some cleanup (and documentation).
> Do you provide a oldconfig-like functionnality ?
Yes, and it's in plain C.
bye, Roman
On Wed, Mar 20, 2002 at 01:35:21PM +0100, Roman Zippel wrote:
> > Don't expect from me (and others I guess) to install the qt2 libs to
> > configure my kernel.
>
> I'm curious, is python+tk any better/worse?
Definetely worse but because of python but you know that already.
I have had a look at libqt2 which is 2MB.
It's not a problem if you provide a menuconfig like functionnality.
> > Is there a clear separation between GUI and other code ?
>
> Yes, although the interface needs some cleanup (and documentation).
Ok I understand that you are at the prototype stage
> > Do you provide a oldconfig-like functionnality ?
>
> Yes, and it's in plain C.
Cool.
Do you take into account in your design that 2.6 will be (perhaps) a
kernel with everything in module ?
Christophe
>
> bye, Roman
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Christophe Barb? <[email protected]>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E
L'experience, c'est une connerie par jour mais jamais la m?me.
Hi,
Below is a first version of the specification, which describes the config
syntax as it's currently generated. It's not complete yet, but IMO ready
for a first review. If you want to see how it works, you can still do it
with http://www.xs4all.nl/~zippel/lc/lc-0.2.tar.gz.
Maybe I should also say, which kind of feedback I'd really like to
have. My main goal is to create a simple, but also easily extendable
configuration system. So before reading the spec below, try the package
and at least create the new configuration file. Then check it out and try
to understand it. Now compare your expectation with the spec below. How
does it compare? Any unpleasant surprises?
It's very important for me to avoid problems here, in the end all kernel
developers have to maintain their configuration information and that is a
point, where I see problems with cml2. (So if you have experience with
cml2, some feedback on how it compares to this, would be of course welcome
too.)
cml2 has several interesting ideas, but IMO Eric skips a step. cml2 became
too complex while trying to implement all this, so I rather concentrate
on the essentially needed things.
Eric, I also would really like to get some feedback from you and your
opinion about this. You worked on this longer than I did. Which parts are
missing here? Can this be extended to describe this?
We really need to make an intermediate step, before we can implement any
new functionality. Your implementation does simply too much and not always
the right thing. Today I was playing with it again and only did a 'make
oldconfig' and it completely modified my configuration. Eric, this is
simply unacceptable. So please let's work on this together to get the
best out of it.
bye, Roman
--
A small overview about the current config language syntax. This syntax
describes all elements which are used by the converter to describe the
cml1 syntax. Every extension, which is currently understood, or any
assumptions made by the config frontends, is still unspecified and
likely to change.
Areas that need better specification:
- relation of multiple definition of the same config symbol (also if one
definition is part of a choice statement)
- relation of menu dependencies and the enclosed config statements
- order dependence between prompts, defaults and dependencies?
- ...
1. basic config statements:
- "config"
- "choice" - "endchoice"
- "source"
- "comment"
- "menu" - "endmenu"
- "mainmenu"
These basic statements start at the beginning of the line. The reason
for this that preceding help entries stop as soon as they find a line
that doesn't start with a space or tab character. This is the best
compromise I found between easy parsing and easy editing of the config.
2. dependencies
Dependencies describe in first place the relation between configuration
symbols and consequently between different parts of the kernel. To
simplify the verification of the rule base, dependencies must be
hierarchical, that means no recursive dependencies are allowed. The only
possible non-hierarchical dependency are exclusions (aka choices), to
cover typical uses during kernel configuration the semantic of choice
statements has been extended (see the choice statement below).
(Currently only the converter warns about recursive dependencies and can
convert some into the new choice syntax).
This allows to describe the following basic relationships:
- initialization order of kernel subsystems. That means which other
subsystems are required (initialized and working), before a specific
subsystem can be initialized itself. This allows above requirement of
hierarchical dependencies.
- mutual exclusions of kernel subsystems. This allows that only a single
of multiple possible subsystems is configured into the kernel.
These are the same relationships, which are reasonably representable
with cml1, but with this new config syntax it should be possible to
easily add further relationships and other properties.
The important usage of the dependency information is for generation of
the menu structure. First it defines whether a symbol or statement is
visible at all. If the dependency expression evaluates to 'n', the symbol
is not visible (and is currently also not saved, this BTW corresponds to
the behavior of xconfig, which is noted as a bug in Documentation/
kbuild/config-language.txt, that didn't seem to be a problem so far, but
that has to be considered).
If a symbol is visible, it defines the possible input range for tristate
symbols, if the dependency expression evaluates to 'm', a tristate symbol
can only be set to 'n' or 'm', otherwise also 'y' is possible.
Finally dependency information is also used to group symbols together.
If a symbol entry is followed by other symbol entries which depends on
the first one, the latter entries are associated with the first entry.
The text config front end uses this information to automatically indent
the entries, the qt interface creates further submenus. This can reduce
the amount of explicit menu information required.
syntax:
This is the syntax of dependency expressions in a yacc-like syntax:
/expr/: /symbol/ (1)
| /symbol/ "=" /symbol/ (2)
| /symbol/ "!=" /symbol/ (3)
| "(" /expr/ ")" (4)
| "!" /expr/ (5)
| /expr/ "&&" /expr/ (6)
| /expr/ "||" /expr/ (7)
Expressions are listed in decreasing order of precedence. An
expression can have a value of 'n', 'm' or 'y' (or 0, 1, 2 respectively
for calculations below).
Every symbol has a name and a value. The name of a symbol can contain
any character, names containing a space or tab character have to be
quoted using single or double quotes (only when a symbol is defined
further restrictions are applied to the name). The possible values of a
symbol depends on its type (boolean, tristate, int, hex, string...). If
a symbol has no type, the name and value are equal. A quoted symbol is
not equal to the unquoted variant and has never a type (the reason for
this is that FOO="FOO" works as expected).
Maybe it's better to ignore above (which basically exposes too much the
implementation and which doesn't exist in this way yet, anyway) and just
follow these basic rules:
- always quote hex, int and string values.
- never quote the name of config symbols.
expression syntax:
(1) Convert the symbol into an expression. Boolean and tristate symbols
are simply converted into the respective expression values. Symbols
with an unknown type are currently converted into 'y' due to
compatibility reasons with cml1, but that will likely change.
(2) If the values of both symbols are equal, it returns 'y', otherwise 'n'.
(3) If the values of both symbols are equal, it returns 'n', otherwise 'y'.
(4) Returns the value of the expression. Used to override precedence.
(5) Returns the result of (2-/expr/).
(6) Returns the result of min(/expr/, /expr/).
(7) Returns the result of max(/expr/, /expr/).
3. "config"
syntax:
"config" /symbol/
/config options/
defines a new config symbol. defining the same config symbol multiple
times is currently undefined.
config options:
"depends" /expr/
defines the visibility and the input range of the config symbol.
"tristate" /prompt/ "if" /expr/
"boolean" /prompt/ "if" /expr/
"int" /prompt/ /symbol/ "if" /expr/
"hex" /prompt/ /symbol/ "if" /expr/
"string" /prompt/ /symbol/ "if" /expr/
defines the type of the symbol and the prompt which is used to request a
value from the user. Additional constraints for the visibility and the
input range of the prompt can be defined after an "if" statement. The
prompt and the "if" statement are optional, but an "if" statement
without a prompt is not possible.
"prompt" /prompt/ /symbol/ "if" /expr/
same as above, but without defining the type of the symbol. This was
generated by earlier versions of the converter and will likely
disappear unless needed otherwise.
"default" /symbol/ "if" /expr/
defines a default value for the config symbol. Default values are only
considered if no prompt is visible. Multiple default statements are
possible and the config symbol is assigned to the first default value
which expression evaluates not to 'n'. The "if" statement is optional.
"help"
defines a help text for this choice statement.
4. "choice"
syntax:
"choice"
/choice options/
/choice block/
"endchoice"
defines a group of related config statements. There are two types of
choice statements - boolean and tristate.
boolean choice: allows only single config statement to be selected and
set to "y".
tristate choice: extends the boolean choice by also allowing multiple
config statement to be selected, but in this mode these will only be set
"m". This can be used if multiple drivers for a single hardware exists
and only a single driver can be compiled/loaded into the kernel, but all
drivers can be compiled as modules.
choice options:
"depends" /expr/
defines the visibility and the input range of the choice.
"prompt" /prompt/
defines the prompt which is presented to the user.
"optional"
by default exactly one of the config statements of a boolean choice has
to be selected, this option allows that also no config statement has to
be selected.
"default" /prompt/
defines the default choice presented to the user. The prompt must be a
unique abbreviation of one config statement prompts (This comes from
cml1, I'll probably change it to the name of the config symbol).
"help"
defines a help text for this choice statement.
choice block:
right now only config statements allowed. (It's possible to also allow
other statements later.)
5. "source"
syntax:
"source" /symbol/
reads the specified configuration file. this is done unconditionally,
(It could be possible to define base dependencies for the statements in
the config file.)
6. "comment"
syntax:
"comment" /prompt/
/comment options/
defines the prompt which is displayed to the user during the
configuration process and is also echoes it to the output files during
output.
comment options:
"depends" /expr/
defines the visibility of the comment.
7. "menu"
syntax:
"menu" /prompt/
/menu options/
/menu block/
"endmenu"
menu options:
"depends" /expr/
defines the visibility of the menu.
menu block:
Any of the basic statements is allowed within a menu block.
8. "mainmenu"
syntax:
"mainmenu" /prompt/
This is the "mainmenu_name" statement from cml1, unless someone finds a
use for it, it will be dropped soon. It's ignored right now.
Hi,
"J.A. Magallon" wrote:
> There is something (as an 'external' viewer) I never understood.
> Why nobody has taken the 'obvious' way ?
> - Perl is much more extended that python and better? than sh for CML.
Because we should get away from a language, what we need are properties.
E.g. a driver has dependencies on other parts of the kernel or has
configuration options and these properties should be expressed as clear
as possible.
bye, Roman