author | kergoth <kergoth> | 2002-10-31 17:11:35 (UTC) |
---|---|---|
committer | kergoth <kergoth> | 2002-10-31 17:11:35 (UTC) |
commit | d955226c2197578f69c510282a4e9ad1ea8fe771 (patch) (unidiff) | |
tree | 0d8f210dd012559df4e3432ccc8ce96e9bd15853 /scripts/kconfig/lkc_spec | |
parent | 16fcb285f9ba7c514fc3f2695768a82feeb7182b (diff) | |
download | opie-d955226c2197578f69c510282a4e9ad1ea8fe771.zip opie-d955226c2197578f69c510282a4e9ad1ea8fe771.tar.gz opie-d955226c2197578f69c510282a4e9ad1ea8fe771.tar.bz2 |
Initial bits to start work on revamping the buildsystem
-rw-r--r-- | scripts/kconfig/lkc_spec | 250 |
1 files changed, 250 insertions, 0 deletions
diff --git a/scripts/kconfig/lkc_spec b/scripts/kconfig/lkc_spec new file mode 100644 index 0000000..45c36eb --- a/dev/null +++ b/scripts/kconfig/lkc_spec | |||
@@ -0,0 +1,250 @@ | |||
1 | 1. General Structure | ||
2 | |||
3 | The configuration file describes a series of menu entries. These menu | ||
4 | entries are organized in a tree structure. The following statements | ||
5 | start a new menu entry definition (and end a previous menu entry): | ||
6 | - config | ||
7 | - choice | ||
8 | - comment | ||
9 | - menu | ||
10 | The following statements are control entries and also end the definition | ||
11 | of a previous menu entry: | ||
12 | - source | ||
13 | - if | ||
14 | |||
15 | 2. Dependencies | ||
16 | |||
17 | Every menu entry has dependencies, which define it's visibility in the | ||
18 | menu structure. What makes these dependencies more difficult is that | ||
19 | they use three states instead of two, that most programmers are familiar | ||
20 | with. The additional 'mod' state is needed to describe drivers which | ||
21 | are not compiled into the kernel, but are compiled as modules, which | ||
22 | can be loaded at runtime. Nevertheless they should be straigthforward | ||
23 | to use. | ||
24 | Dependencies describe in first place the relation between configuration | ||
25 | symbols and consequently between different parts of the kernel. To | ||
26 | simplify the verification of the rule base, dependencies must be | ||
27 | hierarchical, that means no recursive dependencies are allowed. The only | ||
28 | possible non-hierarchical dependency are exclusions (aka choices), to | ||
29 | cover typical uses during kernel configuration the semantic of choice | ||
30 | statements has been extended (see the choice statement below). | ||
31 | |||
32 | This allows to describe the following basic relationships: | ||
33 | - initialization order of kernel subsystems. That means which other | ||
34 | subsystems are required (initialized and working), before a specific | ||
35 | subsystem can be initialized itself. This allows above requirement of | ||
36 | hierarchical dependencies. | ||
37 | - mutual exclusions of kernel subsystems. This allows that only a single | ||
38 | of multiple possible subsystems is configured into the kernel. | ||
39 | These are the same relationships, which are reasonably representable | ||
40 | with cml1, but with this new config syntax it should be possible to | ||
41 | easily add further relationships and other properties. | ||
42 | |||
43 | The important usage of the dependency information is for generation of | ||
44 | the menu structure. First it defines whether a symbol or statement is | ||
45 | visible at all. If the dependency expression evaluates to 'n', the symbol | ||
46 | is not visible (and is currently also not saved, this BTW corresponds to | ||
47 | the behavior of xconfig, which is noted as a bug in Documentation/ | ||
48 | kbuild/config-language.txt, that didn't seem to be a problem so far, but | ||
49 | that has to be considered). | ||
50 | If a symbol is visible, it defines the possible input range for tristate | ||
51 | symbols, if the dependency expression evaluates to 'm', a tristate symbol | ||
52 | can only be set to 'n' or 'm', otherwise also 'y' is possible. | ||
53 | Finally dependency information is also used to group symbols together. | ||
54 | If a symbol entry is followed by other symbol entries which depends on | ||
55 | the first one, the latter entries are associated with the first entry. | ||
56 | The text config front end uses this information to automatically indent | ||
57 | the entries, the qt interface creates further submenus. This can reduce | ||
58 | the amount of explicit menu information required. | ||
59 | |||
60 | syntax: | ||
61 | |||
62 | This is the syntax of dependency expressions: | ||
63 | |||
64 | <expr> ::= <symbol> (1) | ||
65 | <symbol> '=' <symbol> (2) | ||
66 | <symbol> '!=' <symbol> (3) | ||
67 | '(' <expr> ')' (4) | ||
68 | '!' <expr> (5) | ||
69 | <expr> '||' <expr> (6) | ||
70 | <expr> '&&' <expr> (7) | ||
71 | |||
72 | Expressions are listed in decreasing order of precedence. An | ||
73 | expression can have a value of 'n', 'm' or 'y' (or 0, 1, 2 respectively | ||
74 | for calculations below). | ||
75 | There are two type of symbols: constant and nonconstant symbols. | ||
76 | Nonconstant symbols are the most common ones and are defined with the | ||
77 | 'config' statement. Nonconstant symbols consist entirely of alphanumeric | ||
78 | characters or underscores. | ||
79 | Constant symbols are only part of expressions. Constant symbols are | ||
80 | always surrounded by single or double quotes. Within the quote any | ||
81 | other character is allowed and the quotes can be escaped using '\'. | ||
82 | Nonconstant symbols which are nowhere defined with 'config' are a | ||
83 | special case, they behave like constant symbols, so that one can do | ||
84 | "FOO=123", it usage should restricted to number values (this might | ||
85 | be enforced later). | ||
86 | |||
87 | expression syntax: | ||
88 | |||
89 | (1) Convert the symbol into an expression. Boolean and tristate symbols | ||
90 | are simply converted into the respective expression values. All other | ||
91 | symbol types result in 'n'. | ||
92 | (2) If the values of both symbols are equal, it returns 'y', otherwise 'n'. | ||
93 | (3) If the values of both symbols are equal, it returns 'n', otherwise 'y'. | ||
94 | (4) Returns the value of the expression. Used to override precedence. | ||
95 | (5) Returns the result of (2-/expr/). | ||
96 | (6) Returns the result of min(/expr/, /expr/). | ||
97 | (7) Returns the result of max(/expr/, /expr/). | ||
98 | |||
99 | 3. "config" | ||
100 | |||
101 | syntax: | ||
102 | |||
103 | "config" <symbol> | ||
104 | <config options> | ||
105 | |||
106 | Defines a new config symbol. A symbol can be defined multiple times as | ||
107 | long as the symbol type is always the same. | ||
108 | |||
109 | config options: | ||
110 | |||
111 | "depends" <expr> | ||
112 | |||
113 | defines the visibility and the input range of the config symbol. | ||
114 | |||
115 | "tristate" <prompt> "if" <expr> | ||
116 | "bool" <prompt> "if" <expr> | ||
117 | "int" <prompt> "if" <expr> | ||
118 | "hex" <prompt> "if" <expr> | ||
119 | "string" <prompt> "if" <expr> | ||
120 | |||
121 | defines the type of the symbol and the prompt which is used to request a | ||
122 | value from the user. Additional constraints for the visibility and the | ||
123 | input range of the prompt can be defined after an "if" statement. The | ||
124 | prompt and the "if" statement are optional, but an "if" statement | ||
125 | without a prompt is not possible. | ||
126 | |||
127 | "prompt" <prompt> "if" <expr> | ||
128 | |||
129 | same as above, but without defining the type of the symbol. This was | ||
130 | generated by earlier versions of the converter and will likely | ||
131 | disappear unless needed otherwise. | ||
132 | |||
133 | "default" <symbol> "if" <expr> | ||
134 | |||
135 | defines a default value for the config symbol. Unless the config symbol | ||
136 | was previously set by the user, it will set to this value. This means | ||
137 | it will be used as default value for above input prompts or if no user | ||
138 | prompt is visible the config symbol will be saved with this value. If | ||
139 | multiple default statements are visible only the first is used. | ||
140 | |||
141 | "help" | ||
142 | |||
143 | defines a help text for this statement. The end of the help text | ||
144 | is determined by the level indentation, this means it ends at the first | ||
145 | line which has a smaller indentation than the first line of the help text. | ||
146 | |||
147 | 4. "choice" | ||
148 | |||
149 | syntax: | ||
150 | |||
151 | "choice" | ||
152 | <choice options> | ||
153 | <choice block> | ||
154 | "endchoice" | ||
155 | |||
156 | defines a group of related config statements. There are two types of | ||
157 | choice statements - bool and tristate. | ||
158 | |||
159 | bool choice: allows only single config statement to be selected and | ||
160 | set to "y". | ||
161 | tristate choice: extends the bool choice by also allowing multiple | ||
162 | config statement to be selected, but in this mode these will only be set | ||
163 | "m". This can be used if multiple drivers for a single hardware exists | ||
164 | and only a single driver can be compiled/loaded into the kernel, but all | ||
165 | drivers can be compiled as modules. | ||
166 | |||
167 | choice options: | ||
168 | |||
169 | "depends" <expr> | ||
170 | |||
171 | defines the visibility and the input range of the choice. | ||
172 | |||
173 | "prompt" <prompt> | ||
174 | |||
175 | defines the prompt which is presented to the user. | ||
176 | |||
177 | <optional> | ||
178 | |||
179 | by default exactly one of the config statements of a bool choice has | ||
180 | to be selected, this option allows that also no config statement has to | ||
181 | be selected. | ||
182 | |||
183 | "default" <symbol> | ||
184 | |||
185 | defines the default choice presented to the user. The prompt must be a | ||
186 | one of symbols defined within this choice. | ||
187 | |||
188 | "help" | ||
189 | |||
190 | defines a help text for this choice statement. The end of the help text | ||
191 | is determined by the level indentation, this means it ends at the first | ||
192 | line which has a smaller indentation than the first line of the help text. | ||
193 | |||
194 | choice block: | ||
195 | |||
196 | right now only config statements allowed. (It's possible to also allow | ||
197 | other statements later.) | ||
198 | |||
199 | 5. "comment" | ||
200 | |||
201 | syntax: | ||
202 | |||
203 | "comment" <prompt> | ||
204 | <comment options> | ||
205 | |||
206 | defines the prompt which is displayed to the user during the | ||
207 | configuration process and is also echoes it to the output files during | ||
208 | output. | ||
209 | |||
210 | comment options: | ||
211 | |||
212 | "depends" <expr> | ||
213 | |||
214 | defines the visibility of the comment. | ||
215 | |||
216 | 6. "menu" | ||
217 | |||
218 | syntax: | ||
219 | |||
220 | "menu" <prompt> | ||
221 | <menu options> | ||
222 | <menu block> | ||
223 | "endmenu" | ||
224 | |||
225 | menu options: | ||
226 | |||
227 | "depends" <expr> | ||
228 | |||
229 | defines the visibility of the menu. | ||
230 | |||
231 | menu block: | ||
232 | |||
233 | Any of the basic statements is allowed within a menu block. | ||
234 | |||
235 | 7. "if" | ||
236 | |||
237 | syntax: | ||
238 | |||
239 | "if" <expr> | ||
240 | <if block> | ||
241 | "endif" | ||
242 | |||
243 | 8. "source" | ||
244 | |||
245 | syntax: | ||
246 | |||
247 | "source" <prompt> | ||
248 | |||
249 | reads the specified configuration file. this is done unconditionally, | ||
250 | |||