OpenCores
URL https://opencores.org/ocsvn/openrisc/openrisc/trunk

Subversion Repositories openrisc

[/] [openrisc/] [trunk/] [rtos/] [ecos-2.0/] [doc/] [html/] [cdl-guide/] [language.naming.html] - Blame information for rev 375

Go to most recent revision | Details | Compare with Previous | View Log

Line No. Rev Author Line
1 28 unneback
<!-- Copyright (C) 2003 Red Hat, Inc.                                -->
2
<!-- This material may be distributed only subject to the terms      -->
3
<!-- and conditions set forth in the Open Publication License, v1.0  -->
4
<!-- or later (the latest version is presently available at          -->
5
<!-- http://www.opencontent.org/openpub/).                           -->
6
<!-- Distribution of the work or derivative of the work in any       -->
7
<!-- standard (paper) book form is prohibited unless prior           -->
8
<!-- permission is obtained from the copyright holder.               -->
9
<HTML
10
><HEAD
11
><TITLE
12
>Option Naming Convention</TITLE
13
><meta name="MSSmartTagsPreventParsing" content="TRUE">
14
<META
15
NAME="GENERATOR"
16
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
17
"><LINK
18
REL="HOME"
19
TITLE="The eCos Component Writer's Guide"
20
HREF="cdl-guide.html"><LINK
21
REL="UP"
22
TITLE="The CDL Language"
23
HREF="language.html"><LINK
24
REL="PREVIOUS"
25
TITLE="CDL Properties"
26
HREF="language.properties.html"><LINK
27
REL="NEXT"
28
TITLE="An Introduction to Tcl"
29
HREF="language.tcl.html"></HEAD
30
><BODY
31
CLASS="SECT1"
32
BGCOLOR="#FFFFFF"
33
TEXT="#000000"
34
LINK="#0000FF"
35
VLINK="#840084"
36
ALINK="#0000FF"
37
><DIV
38
CLASS="NAVHEADER"
39
><TABLE
40
SUMMARY="Header navigation table"
41
WIDTH="100%"
42
BORDER="0"
43
CELLPADDING="0"
44
CELLSPACING="0"
45
><TR
46
><TH
47
COLSPAN="3"
48
ALIGN="center"
49
>The <SPAN
50
CLASS="APPLICATION"
51
>eCos</SPAN
52
> Component Writer's Guide</TH
53
></TR
54
><TR
55
><TD
56
WIDTH="10%"
57
ALIGN="left"
58
VALIGN="bottom"
59
><A
60
HREF="language.properties.html"
61
ACCESSKEY="P"
62
>Prev</A
63
></TD
64
><TD
65
WIDTH="80%"
66
ALIGN="center"
67
VALIGN="bottom"
68
>Chapter 3. The CDL Language</TD
69
><TD
70
WIDTH="10%"
71
ALIGN="right"
72
VALIGN="bottom"
73
><A
74
HREF="language.tcl.html"
75
ACCESSKEY="N"
76
>Next</A
77
></TD
78
></TR
79
></TABLE
80
><HR
81
ALIGN="LEFT"
82
WIDTH="100%"></DIV
83
><DIV
84
CLASS="SECT1"
85
><H1
86
CLASS="SECT1"
87
><A
88
NAME="LANGUAGE.NAMING">Option Naming Convention</H1
89
><P
90
>All the options in a given configuration live in the same namespace.
91
Furthermore it is not possible for two separate options to have the
92
same name, because this would make any references to those options in
93
<SPAN
94
CLASS="APPLICATION"
95
>CDL</SPAN
96
> expressions ambiguous. A naming convention exists to avoid
97
problems. It is recommended that component writers observe some or all
98
of this convention to reduce the probability of name clashes with
99
other packages.</P
100
><P
101
>There is an important restriction on option names. Typically the
102
component framework will output a <TT
103
CLASS="LITERAL"
104
>#define</TT
105
> for every
106
active and enabled option, using the name as the symbol being defined.
107
This requires that all names are valid C preprocessor symbols, a
108
limitation that is enforced even for options which have the
109
<SPAN
110
CLASS="PROPERTY"
111
>no_define</SPAN
112
> property. Preprocessor symbols can be any sequence of
113
lower case letters <TT
114
CLASS="LITERAL"
115
>a</TT
116
>-<TT
117
CLASS="LITERAL"
118
>z</TT
119
>, upper
120
case letters, <TT
121
CLASS="LITERAL"
122
>A</TT
123
>-<TT
124
CLASS="LITERAL"
125
>Z</TT
126
>, the
127
underscore character <TT
128
CLASS="LITERAL"
129
>_</TT
130
>, and the digits
131
<TT
132
CLASS="LITERAL"
133
>0</TT
134
>-<TT
135
CLASS="LITERAL"
136
>9</TT
137
>. The first character must be
138
a non-digit. Using an underscore as the first character is
139
discouraged, because that may clash with reserved language
140
identifiers. In addition there is a convention that preprocessor
141
symbols only use upper case letters, and some component writers may
142
wish to follow this convention.</P
143
><P
144
>A typical option name could be something like
145
<TT
146
CLASS="VARNAME"
147
>CYGSEM_KERNEL_SCHED_BITMAP</TT
148
>. This name consists of
149
several different parts:</P
150
><P
151
></P
152
><OL
153
TYPE="1"
154
><LI
155
><P
156
>The first few characters, in this case the three letters
157
<TT
158
CLASS="LITERAL"
159
>CYG</TT
160
>, are used to identify the organization that
161
produced the package. For historical reasons packages produced by Red
162
Hat tend to use the prefix <TT
163
CLASS="LITERAL"
164
>CYG</TT
165
> rather than
166
<TT
167
CLASS="LITERAL"
168
>RHAT</TT
169
>. Component writers should use their own
170
prefix: even when cutting and pasting from an existing <SPAN
171
CLASS="APPLICATION"
172
>CDL</SPAN
173
> script
174
the prefix should be changed to something appropriate to their
175
organization. </P
176
><P
177
>It can be argued that a short prefix, often limited to upper case
178
letters, is not sufficiently long to eliminate the possibility of
179
name clashes. A longer prefix could be used, for example one based on
180
internet domain names. However the C preprocessor has no concept of
181
namespaces or <TT
182
CLASS="LITERAL"
183
>import</TT
184
> directives, so it would always
185
be necessary to use the full option name in component source code
186
which gets tedious - option names tend to be long enough as it is.
187
There is a small increased risk of name clashes, but this risk is felt
188
to be acceptable.</P
189
></LI
190
><LI
191
><P
192
>The next three characters indicate the nature of the option, for
193
example whether it affects the interface or just the implementation. A
194
list of common tags is given below.</P
195
></LI
196
><LI
197
><P
198
>The <TT
199
CLASS="LITERAL"
200
>KERNEL_SCHED</TT
201
> part indicates the location of the
202
option within the overall hierarchy. In this case the option is part of
203
the scheduling component of the kernel package. Having the hierarchy
204
details as part of the option name can help in understanding
205
configurable code and further reduces the probability of a name clash.</P
206
></LI
207
><LI
208
><P
209
>The final part, <TT
210
CLASS="LITERAL"
211
>BITMAP</TT
212
>, identifies the option
213
itself. </P
214
></LI
215
></OL
216
><P
217
>The three-character tag is intended to provide some additional
218
information about the nature of the option. There are a number of
219
pre-defined tags. However for many options there is a choice:
220
options related to the platform should normally use
221
<TT
222
CLASS="LITERAL"
223
>HWR</TT
224
>, but numerical options should normally use
225
<TT
226
CLASS="LITERAL"
227
>NUM</TT
228
>; a platform-related numerical option such as
229
the size of an interrupt stack could therefore use either tag.
230
There are no absolute rules, and it is left to component writers to
231
interpret the following guidelines:</P
232
><P
233
></P
234
><DIV
235
CLASS="VARIABLELIST"
236
><DL
237
><DT
238
><TT
239
CLASS="LITERAL"
240
>xxxARC_</TT
241
></DT
242
><DD
243
><P
244
>The <TT
245
CLASS="LITERAL"
246
>ARC</TT
247
> tag is intended for options related
248
to the processor architecture. Typically such options will only occur
249
in architectural or variant HAL packages.</P
250
></DD
251
><DT
252
><TT
253
CLASS="LITERAL"
254
>xxxHWR_</TT
255
></DT
256
><DD
257
><P
258
>The <TT
259
CLASS="LITERAL"
260
>HWR</TT
261
> tag is intended for options related to
262
the specific target board. Typically such options will only occur in
263
platform HAL packages.</P
264
></DD
265
><DT
266
><TT
267
CLASS="LITERAL"
268
>xxxPKG_</TT
269
></DT
270
><DD
271
><P
272
>This tag is intended for packages or components, in other words
273
options which extend the configuration hierarchy. Arguably a
274
<TT
275
CLASS="LITERAL"
276
>COM</TT
277
> tag would be more appropriate for
278
components, but this could be confusing because of the considerable
279
number of computing terms that begin with com.</P
280
></DD
281
><DT
282
><TT
283
CLASS="LITERAL"
284
>xxxGLO_</TT
285
></DT
286
><DD
287
><P
288
>This is intended for global configuration options, especially
289
preferences.</P
290
></DD
291
><DT
292
><TT
293
CLASS="LITERAL"
294
>xxxDBG_</TT
295
></DT
296
><DD
297
><P
298
>The <TT
299
CLASS="LITERAL"
300
>DBG</TT
301
> tag indicates that the option is in
302
some way related to debugging, for example it may enable assertions in
303
some part of the system.</P
304
></DD
305
><DT
306
><TT
307
CLASS="LITERAL"
308
>xxxTST_</TT
309
></DT
310
><DD
311
><P
312
>This tag is for testing-related options. Typically these do not
313
affect actual application code, instead they control the interaction
314
between target-side test cases and a host-side testing infrastructure.</P
315
></DD
316
><DT
317
><TT
318
CLASS="LITERAL"
319
>xxxFUN_</TT
320
></DT
321
><DD
322
><P
323
>This is for configuration options which affect the interface of a
324
package. There are a number of related tag which are also
325
interface-related. <TT
326
CLASS="LITERAL"
327
>xxxFUN_</TT
328
> is intended primarily
329
for options that control whether or not one or more functions are
330
provided by the package, but can also be used if none of the other
331
interface-related tags is applicable.</P
332
></DD
333
><DT
334
><TT
335
CLASS="LITERAL"
336
>xxxVAR_</TT
337
></DT
338
><DD
339
><P
340
>This is analogous to <TT
341
CLASS="LITERAL"
342
>FUN</TT
343
> but controls the presence
344
or absence of one or more variables or objects.</P
345
></DD
346
><DT
347
><TT
348
CLASS="LITERAL"
349
>xxxCLS_</TT
350
></DT
351
><DD
352
><P
353
>The <TT
354
CLASS="LITERAL"
355
>CLS</TT
356
> tag is intended only for packages that
357
provide an object-oriented interface, and controls the presence or
358
absence of an entire class.</P
359
></DD
360
><DT
361
><TT
362
CLASS="LITERAL"
363
>xxxMFN_</TT
364
></DT
365
><DD
366
><P
367
>This is also for object-orientated interfaces, and indicates the
368
presence or absence of a member function rather than an entire class.</P
369
></DD
370
><DT
371
><TT
372
CLASS="LITERAL"
373
>xxxSEM_</TT
374
></DT
375
><DD
376
><P
377
>A <TT
378
CLASS="LITERAL"
379
>SEM</TT
380
> option does not affect the interface (or if
381
does affect the interface, this is incidental). Instead it is used for
382
options which have a fundamental effect on the semantic behavior of a
383
package. For example the choice of kernel schedulers is semantic in
384
nature: it does not affect the interface, in particular the function
385
<TT
386
CLASS="FUNCTION"
387
>cyg_thread_create</TT
388
> exists irrespective of which
389
scheduler has been selected. However it does have a major impact on
390
the system's behavior.</P
391
></DD
392
><DT
393
><TT
394
CLASS="LITERAL"
395
>xxxIMP_</TT
396
></DT
397
><DD
398
><P
399
><TT
400
CLASS="LITERAL"
401
>IMP</TT
402
> is for implementation options. These do not
403
affect either the interface or the semantic behavior (with the
404
possible exception of timing-related changes). A typical
405
implementation option controls whether or not a particular function or
406
set of functions should get inlined.</P
407
></DD
408
><DT
409
><TT
410
CLASS="LITERAL"
411
>xxxNUM_</TT
412
></DT
413
><DD
414
><P
415
>This tag is for numerical options, for example the number of
416
scheduling priority levels.</P
417
></DD
418
><DT
419
><TT
420
CLASS="LITERAL"
421
>xxxDAT_</TT
422
></DT
423
><DD
424
><P
425
>This is for data items that are not numerical in nature, for example a
426
device name.</P
427
></DD
428
><DT
429
><TT
430
CLASS="LITERAL"
431
>xxxBLD_</TT
432
></DT
433
><DD
434
><P
435
>The <TT
436
CLASS="LITERAL"
437
>BLD</TT
438
> tag indicates an option that affects
439
the build process, for example compiler flag settings.</P
440
></DD
441
><DT
442
><TT
443
CLASS="LITERAL"
444
>xxxINT_</TT
445
></DT
446
><DD
447
><P
448
>This should normally be used for <SPAN
449
CLASS="APPLICATION"
450
>CDL</SPAN
451
> interfaces, which is a language
452
construct that is largely independent from the interface exported by a
453
package via its header files. For more details of <SPAN
454
CLASS="APPLICATION"
455
>CDL</SPAN
456
> interfaces
457
see <A
458
HREF="language.interface.html"
459
>the Section called <I
460
>Interfaces</I
461
></A
462
>.</P
463
></DD
464
><DT
465
><TT
466
CLASS="LITERAL"
467
>xxxPRI_</TT
468
></DT
469
><DD
470
><P
471
>This tag is not normally used for configuration options. Instead
472
it is used by <SPAN
473
CLASS="APPLICATION"
474
>CDL</SPAN
475
> scripts to pass additional private information to
476
the source code via the configuration header files, typically inside a
477
<SPAN
478
CLASS="PROPERTY"
479
>define_proc</SPAN
480
> property.</P
481
></DD
482
><DT
483
><TT
484
CLASS="LITERAL"
485
>xxxSRC_</TT
486
></DT
487
><DD
488
><P
489
>This tag is not normally used for configuration options. Instead
490
it can be used by package source code to interact with such options,
491
especially in the context of the <SPAN
492
CLASS="PROPERTY"
493
>if_define</SPAN
494
> property.</P
495
></DD
496
></DL
497
></DIV
498
><P
499
>There is one special case of a potential name clash that is worth
500
mentioning here. When the component framework generates a
501
configuration header file for a given package, by default it will use
502
a name derived from the package name (the <SPAN
503
CLASS="PROPERTY"
504
>define_header</SPAN
505
> property can
506
be used to override this). The file name is constructed from the
507
package name by removing everything up to and including the first
508
underscore, converting the remainder of the name to lower case, and
509
appending a <TT
510
CLASS="LITERAL"
511
>.h</TT
512
> suffix. For example the kernel
513
package <TT
514
CLASS="VARNAME"
515
>CYGPKG_KERNEL</TT
516
> will involve a header file
517
<TT
518
CLASS="FILENAME"
519
>pkgconf/kernel.h</TT
520
>. If a
521
configuration contained some other package
522
<TT
523
CLASS="VARNAME"
524
>XYZPKG_KERNEL</TT
525
> then this would attempt to use the
526
same configuration header file, with unfortunate effects. Case
527
sensitivity could introduce problems as well, so a package
528
<TT
529
CLASS="VARNAME"
530
>xyzpkg_kernel</TT
531
> would involve the same problem. Even
532
if the header file names preserved the case of the package name, not
533
all file systems are case sensitive. There is no simple solution to
534
this problem. Changing the names of the generated configuration header
535
files would involve a major incompatible change to the interface, to
536
solve a problem which is essentially hypothetical in nature.</P
537
></DIV
538
><DIV
539
CLASS="NAVFOOTER"
540
><HR
541
ALIGN="LEFT"
542
WIDTH="100%"><TABLE
543
SUMMARY="Footer navigation table"
544
WIDTH="100%"
545
BORDER="0"
546
CELLPADDING="0"
547
CELLSPACING="0"
548
><TR
549
><TD
550
WIDTH="33%"
551
ALIGN="left"
552
VALIGN="top"
553
><A
554
HREF="language.properties.html"
555
ACCESSKEY="P"
556
>Prev</A
557
></TD
558
><TD
559
WIDTH="34%"
560
ALIGN="center"
561
VALIGN="top"
562
><A
563
HREF="cdl-guide.html"
564
ACCESSKEY="H"
565
>Home</A
566
></TD
567
><TD
568
WIDTH="33%"
569
ALIGN="right"
570
VALIGN="top"
571
><A
572
HREF="language.tcl.html"
573
ACCESSKEY="N"
574
>Next</A
575
></TD
576
></TR
577
><TR
578
><TD
579
WIDTH="33%"
580
ALIGN="left"
581
VALIGN="top"
582
>CDL Properties</TD
583
><TD
584
WIDTH="34%"
585
ALIGN="center"
586
VALIGN="top"
587
><A
588
HREF="language.html"
589
ACCESSKEY="U"
590
>Up</A
591
></TD
592
><TD
593
WIDTH="33%"
594
ALIGN="right"
595
VALIGN="top"
596
>An Introduction to Tcl</TD
597
></TR
598
></TABLE
599
></DIV
600
></BODY
601
></HTML
602
>

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.