1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
|
1. General Structure
The configuration file describes a series of menu entries. These menu
entries are organized in a tree structure. The following statements
start a new menu entry definition (and end a previous menu entry):
- config
- choice
- comment
- menu
The following statements are control entries and also end the definition
of a previous menu entry:
- source
- if
2. Dependencies
Every menu entry has dependencies, which define it's visibility in the
menu structure. What makes these dependencies more difficult is that
they use three states instead of two, that most programmers are familiar
with. The additional 'mod' state is needed to describe drivers which
are not compiled into the kernel, but are compiled as modules, which
can be loaded at runtime. Nevertheless they should be straigthforward
to use.
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).
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:
<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).
There are two type of symbols: constant and nonconstant symbols.
Nonconstant symbols are the most common ones and are defined with the
'config' statement. Nonconstant symbols consist entirely of alphanumeric
characters or underscores.
Constant symbols are only part of expressions. Constant symbols are
always surrounded by single or double quotes. Within the quote any
other character is allowed and the quotes can be escaped using '\'.
Nonconstant symbols which are nowhere defined with 'config' are a
special case, they behave like constant symbols, so that one can do
"FOO=123", it usage should restricted to number values (this might
be enforced later).
expression syntax:
(1) Convert the symbol into an expression. Boolean and tristate symbols
are simply converted into the respective expression values. All other
symbol types result in 'n'.
(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. A symbol can be defined multiple times as
long as the symbol type is always the same.
config options:
"depends" <expr>
defines the visibility and the input range of the config symbol.
"tristate" <prompt> "if" <expr>
"bool" <prompt> "if" <expr>
"int" <prompt> "if" <expr>
"hex" <prompt> "if" <expr>
"string" <prompt> "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> "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. Unless the config symbol
was previously set by the user, it will set to this value. This means
it will be used as default value for above input prompts or if no user
prompt is visible the config symbol will be saved with this value. If
multiple default statements are visible only the first is used.
"help"
defines a help text for this statement. The end of the help text
is determined by the level indentation, this means it ends at the first
line which has a smaller indentation than the first line of the help text.
4. "choice"
syntax:
"choice"
<choice options>
<choice block>
"endchoice"
defines a group of related config statements. There are two types of
choice statements - bool and tristate.
bool choice: allows only single config statement to be selected and
set to "y".
tristate choice: extends the bool 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 bool choice has
to be selected, this option allows that also no config statement has to
be selected.
"default" <symbol>
defines the default choice presented to the user. The prompt must be a
one of symbols defined within this choice.
"help"
defines a help text for this choice statement. The end of the help text
is determined by the level indentation, this means it ends at the first
line which has a smaller indentation than the first line of the help text.
choice block:
right now only config statements allowed. (It's possible to also allow
other statements later.)
5. "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.
6. "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.
7. "if"
syntax:
"if" <expr>
<if block>
"endif"
8. "source"
syntax:
"source" <prompt>
reads the specified configuration file. this is done unconditionally,
|
