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

Subversion Repositories openrisc

[/] [openrisc/] [trunk/] [rtos/] [ecos-2.0/] [doc/] [html/] [cdl-guide/] [overview.html] - Blame information for rev 174

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
>Overview</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="PREVIOUS"
22
TITLE="The eCos Component Writer's Guide"
23
HREF="cdl-guide.html"><LINK
24
REL="NEXT"
25
TITLE="Why Configurability?"
26
HREF="overview.configurability.html"></HEAD
27
><BODY
28
CLASS="CHAPTER"
29
BGCOLOR="#FFFFFF"
30
TEXT="#000000"
31
LINK="#0000FF"
32
VLINK="#840084"
33
ALINK="#0000FF"
34
><DIV
35
CLASS="NAVHEADER"
36
><TABLE
37
SUMMARY="Header navigation table"
38
WIDTH="100%"
39
BORDER="0"
40
CELLPADDING="0"
41
CELLSPACING="0"
42
><TR
43
><TH
44
COLSPAN="3"
45
ALIGN="center"
46
>The <SPAN
47
CLASS="APPLICATION"
48
>eCos</SPAN
49
> Component Writer's Guide</TH
50
></TR
51
><TR
52
><TD
53
WIDTH="10%"
54
ALIGN="left"
55
VALIGN="bottom"
56
><A
57
HREF="cdl-guide.html"
58
ACCESSKEY="P"
59
>Prev</A
60
></TD
61
><TD
62
WIDTH="80%"
63
ALIGN="center"
64
VALIGN="bottom"
65
></TD
66
><TD
67
WIDTH="10%"
68
ALIGN="right"
69
VALIGN="bottom"
70
><A
71
HREF="overview.configurability.html"
72
ACCESSKEY="N"
73
>Next</A
74
></TD
75
></TR
76
></TABLE
77
><HR
78
ALIGN="LEFT"
79
WIDTH="100%"></DIV
80
><DIV
81
CLASS="CHAPTER"
82
><H1
83
><A
84
NAME="OVERVIEW">Chapter 1. Overview</H1
85
><DIV
86
CLASS="TOC"
87
><DL
88
><DT
89
><B
90
>Table of Contents</B
91
></DT
92
><DT
93
><A
94
HREF="overview.html#OVERVIEW.TERMINOLOGY"
95
>Terminology</A
96
></DT
97
><DT
98
><A
99
HREF="overview.configurability.html"
100
>Why Configurability?</A
101
></DT
102
><DT
103
><A
104
HREF="overview.approaches.html"
105
>Approaches to Configurability</A
106
></DT
107
><DT
108
><A
109
HREF="overview.degress.html"
110
>Degrees of Configurability</A
111
></DT
112
><DT
113
><A
114
HREF="overview.warning.html"
115
>Warnings</A
116
></DT
117
></DL
118
></DIV
119
><P
120
><SPAN
121
CLASS="APPLICATION"
122
>eCos</SPAN
123
> was designed from the very beginning as a configurable
124
component architecture. The core <SPAN
125
CLASS="APPLICATION"
126
>eCos</SPAN
127
> system consists of a number of
128
different components such as the kernel, the C library, an
129
infrastructure package. Each of these provides a large number of
130
configuration options, allowing application developers to build a
131
system that matches the requirements of their particular application.
132
To manage the potential complexity of multiple components and lots of
133
configuration options, <SPAN
134
CLASS="APPLICATION"
135
>eCos</SPAN
136
> comes with a component framework: a
137
collection of tools specifically designed to support configuring
138
multiple components. Furthermore this component framework is
139
extensible, allowing additional components to be added to the system
140
at any time.</P
141
><DIV
142
CLASS="SECT1"
143
><H1
144
CLASS="SECT1"
145
><A
146
NAME="OVERVIEW.TERMINOLOGY">Terminology</H1
147
><P
148
>The <SPAN
149
CLASS="APPLICATION"
150
>eCos</SPAN
151
> component architecture involves a number of key concepts.</P
152
><DIV
153
CLASS="SECT2"
154
><H2
155
CLASS="SECT2"
156
><A
157
NAME="CONCEPTS.TERMINOLOGY.FRAMEWORK">Component Framework</H2
158
><P
159
>The phrase <SPAN
160
CLASS="phrase"
161
><SPAN
162
CLASS="PHRASE"
163
>component framework</SPAN
164
></SPAN
165
> is used to describe
166
the collection of tools that allow users to configure a system and
167
administer a component repository. This includes the <SPAN
168
CLASS="APPLICATION"
169
>ecosconfig</SPAN
170
> command line tool, the
171
graphical configuration tool, and the package administration tool.
172
Both the command line and graphical tools are based on a single
173
underlying library, the <SPAN
174
CLASS="APPLICATION"
175
>CDL</SPAN
176
> library.</P
177
></DIV
178
><DIV
179
CLASS="SECT2"
180
><H2
181
CLASS="SECT2"
182
><A
183
NAME="CONCEPTS.TERMINOLOGY.OPTION">Configuration Option</H2
184
><P
185
>The option is the basic unit of configurability. Typically each option
186
corresponds to a single choice that a user can make. For example there
187
is an option to control whether or not assertions are enabled, and the
188
kernel provides an option corresponding to the number of scheduling
189
priority levels in the system. Options can control very small amounts
190
of code such as whether or not the C library's
191
<TT
192
CLASS="FUNCTION"
193
>strtok</TT
194
> gets inlined. They can also control quite
195
large amounts of code, for example whether or not the
196
<TT
197
CLASS="FUNCTION"
198
>printf</TT
199
> supports floating point conversions.</P
200
><P
201
>Many options are straightforward, and the user only gets to choose
202
whether the option is enabled or disabled. Some options are more
203
complicated, for example the number of scheduling priority levels is a
204
number that should be within a certain range. Options should always
205
start off with a sensible default setting, so that it is not necessary
206
for users to make hundreds of decisions before any work can start on
207
developing the application. Once the application is running the
208
various configuration options can be used to tune the system for the
209
specific needs of the application.</P
210
><P
211
>The component framework allows for options that are not directly
212
user-modifiable. Consider the case of processor endianness: some
213
processors are always big-endian or always little-endian, while with
214
other processors there is a choice. Depending on the user's choice of
215
target hardware, endianness may or may not be user-modifiable.</P
216
></DIV
217
><DIV
218
CLASS="SECT2"
219
><H2
220
CLASS="SECT2"
221
><A
222
NAME="CONCEPTS.TERMINOLOGY.COMPONENT">Component</H2
223
><P
224
>A component is a unit of functionality such as a particular kernel
225
scheduler or a device driver for a specific device. A component is
226
also a configuration option in that users may want to enable
227
or disable all the functionality in a component. For example, if a
228
particular device on the target hardware is not going to be used by
229
the application, directly or indirectly, then there is no point in
230
having a device driver for it. Furthermore disabling the device driver
231
should reduce the memory requirements for both code and data.</P
232
><P
233
>Components may contain further configuration options. In the case of a
234
device driver, there may be options to control the exact behavior of
235
that driver. These will of course be irrelevant if the driver as a
236
whole is disabled. More generally options and components live in a
237
hierarchy, where any component can contain options specific to that
238
component and further sub-components. It is possible to view the
239
entire <SPAN
240
CLASS="APPLICATION"
241
>eCos</SPAN
242
> kernel as one big component, containing sub-components
243
for scheduling, exception handling, synchronization primitives, and so
244
on. The synchronization primitives component can contain further
245
sub-components for mutexes, semaphores, condition variables, event
246
flags, and so on. The mutex component can contain configuration
247
options for issues like priority inversion support.</P
248
></DIV
249
><DIV
250
CLASS="SECT2"
251
><H2
252
CLASS="SECT2"
253
><A
254
NAME="CONCEPTS.TERMINOLOGY.PACKAGE">Package</H2
255
><P
256
>A package is a special type of component. Specifically, a package is
257
the unit of distribution of components. It is possible to create a
258
distribution file for a package containing all of the source code,
259
header files, documentation, and other relevant files. This
260
distribution file can then be installed using the appropriate tool.
261
Afterwards it is possible to uninstall that package, or to install a
262
later version. The core <SPAN
263
CLASS="APPLICATION"
264
>eCos</SPAN
265
> distribution comes with a number of
266
packages such as the kernel and the infrastructure. Other packages
267
such as network stacks can come from various different sources and can
268
be installed alongside the core distribution.</P
269
><P
270
>Packages can be enabled or disabled, but the user experience is a
271
little bit different. Generally it makes no sense for the tools to
272
load the details of every single package that has been installed. For
273
example, if the target hardware uses an ARM processor then there is no
274
point in loading the HAL packages for other architectures and
275
displaying choices to the user which are not relevant. Therefore
276
enabling a package means loading its configuration data into the
277
appropriate tool, and disabling a package is an unload operation. In
278
addition, packages are not just enabled or disabled: it is also
279
possible to select the particular version of a package that should be
280
used.</P
281
></DIV
282
><DIV
283
CLASS="SECT2"
284
><H2
285
CLASS="SECT2"
286
><A
287
NAME="CONCEPTS.TERMINOLOGY.CONFIGURATION">Configuration</H2
288
><P
289
>A configuration is a collection of user choices. The various
290
tools that make up the component framework deal with entire
291
configurations. Users can create a new configuration, output a
292
savefile (by default <TT
293
CLASS="FILENAME"
294
>ecos.ecc</TT
295
>), manipulate a
296
configuration, and use a configuration to generate a build tree prior
297
to building <SPAN
298
CLASS="APPLICATION"
299
>eCos</SPAN
300
> and any other packages that have been selected.
301
A configuration includes details such as which packages have been
302
selected, in addition to finer-grained information such as which
303
options in those packages have been enabled or disabled by the user. </P
304
></DIV
305
><DIV
306
CLASS="SECT2"
307
><H2
308
CLASS="SECT2"
309
><A
310
NAME="CONCEPTS.TERMINOLOGY.TARGET">Target</H2
311
><P
312
>The target is the specific piece of hardware on which the application
313
is expected to run. This may be an off-the-shelf evaluation board, a
314
piece of custom hardware intended for a specific application, or it
315
could be something like a simulator. One of the steps when creating a
316
new configuration is need to specify the target. The component
317
framework will map this on to a set of packages that are used to
318
populate the configuration, typically HAL and device driver packages,
319
and in addition it may cause certain options to be changed from their
320
default settings to something more appropriate for the
321
specified target.</P
322
></DIV
323
><DIV
324
CLASS="SECT2"
325
><H2
326
CLASS="SECT2"
327
><A
328
NAME="CONCEPTS.TERMINOLOGY.TEMPLATE">Template</H2
329
><P
330
>A template is a partial configuration, aimed at providing users with
331
an appropriate starting point. <SPAN
332
CLASS="APPLICATION"
333
>eCos</SPAN
334
> is shipped with a small number
335
of templates, which correspond closely to common ways of using the
336
system. There is a minimal template which provides very little
337
functionality, just enough to bootstrap the hardware and then jump
338
directly to application code. The default template adds additional
339
functionality, for example it causes the kernel and C library packages
340
to be loaded as well. The uitron template adds further functionality
341
in the form of a &micro;ITRON compatibility layer. Creating a new
342
configuration typically involves specifying a template as well as a
343
target, resulting in a configuration that can be built and linked with
344
the application code and that will run on the actual hardware. It is
345
then possible to fine-tune configuration options to produce something
346
that better matches the specific requirements of the application.</P
347
></DIV
348
><DIV
349
CLASS="SECT2"
350
><H2
351
CLASS="SECT2"
352
><A
353
NAME="CONCEPTS.TERMINOLOGY.PROPERTIES">Properties</H2
354
><P
355
>The component framework needs a certain amount of information about
356
each option. For example it needs to know what the legal values are,
357
what the default should be, where to find the on-line documentation if
358
the user needs to consult that in order to make a decision, and so on.
359
These are all properties of the option. Every option (including
360
components and packages) consists of a name and a set of properties.</P
361
></DIV
362
><DIV
363
CLASS="SECT2"
364
><H2
365
CLASS="SECT2"
366
><A
367
NAME="CONCEPTS.TERMINOLOGY.CONSEQUENCES">Consequences</H2
368
><P
369
>Choices must have consequences. For an <SPAN
370
CLASS="APPLICATION"
371
>eCos</SPAN
372
> configuration the main
373
end product is a library that can be linked with application code, so
374
the consequences of a user choice must affect the build process. This
375
happens in two main ways. First, options can affect which files get
376
built and end up in the library. Second, details of the current option
377
settings get written into various configuration header files using C
378
preprocessor <TT
379
CLASS="LITERAL"
380
>#define</TT
381
> directives, and package source
382
code can <TT
383
CLASS="LITERAL"
384
>#include</TT
385
> these configuration headers and
386
adapt accordingly. This allows options to affect a package at a very
387
fine grain, at the level of individual lines in a source file if
388
desired. There may be other consequences as well, for example there
389
are options to control the compiler flags that get used during the
390
build process.</P
391
></DIV
392
><DIV
393
CLASS="SECT2"
394
><H2
395
CLASS="SECT2"
396
><A
397
NAME="CONCEPTS.TERMINOLOGY.CONSTRAINTS">Constraints</H2
398
><P
399
>Configuration choices are not independent. The C library can provide
400
thread-safe implementations of functions like
401
<TT
402
CLASS="FUNCTION"
403
>rand</TT
404
>, but only if the kernel provides support for
405
per-thread data. This is a constraint: the C library option has a
406
requirement on the kernel. A typical configuration involves a
407
considerable number of constraints, of varying complexity: many
408
constraints are straightforward, option <TT
409
CLASS="LITERAL"
410
>A</TT
411
> requires
412
option <TT
413
CLASS="LITERAL"
414
>B</TT
415
>, or option <TT
416
CLASS="LITERAL"
417
>C</TT
418
> precludes
419
option <TT
420
CLASS="LITERAL"
421
>D</TT
422
>. Other constraints can be more
423
complicated, for example option <TT
424
CLASS="LITERAL"
425
>E</TT
426
> may require the
427
presence of a kernel scheduler but does not care whether it is the
428
bitmap scheduler, the mlqueue scheduler, or something else.</P
429
><P
430
>Another type of constraint involves the values that can be used for
431
certain options. For example there is a kernel option related to the
432
number of scheduling levels, and there is a legal values constraint on
433
this option: specifying zero or a negative number for the number of
434
scheduling levels makes no sense.</P
435
></DIV
436
><DIV
437
CLASS="SECT2"
438
><H2
439
CLASS="SECT2"
440
><A
441
NAME="CONCEPTS.TERMINOLOGY.CONFLICTS">Conflicts</H2
442
><P
443
>As the user manipulates options it is possible to end up with an
444
invalid configuration, where one or more constraints are not
445
satisfied. For example if kernel per-thread data is disabled but the C
446
library's thread-safety options are left enabled then there are
447
unsatisfied constraints, also known as conflicts. Such conflicts will
448
be reported by the configuration tools. The presence of conflicts does
449
not prevent users from attempting to build <SPAN
450
CLASS="APPLICATION"
451
>eCos</SPAN
452
>, but the
453
consequences are undefined: there may be compile-time failures, there
454
may be link-time failures, the application may completely fail to run,
455
or the application may run most of the time but once in a while there
456
will be a strange failure&#8230; Typically users will want to resolve
457
all conflicts before continuing.</P
458
><P
459
>To make things easier for the user, the configuration tools contain an
460
inference engine. This can examine a conflict in a particular
461
configuration and try to figure out some way of resolving the
462
conflict. Depending on the particular tool being used, the inference
463
engine may get invoked automatically at certain times or the user may
464
need to invoke it explicitly. Also depending on the tool, the
465
inference engine may apply any solutions it finds automatically or it
466
may request user confirmation.</P
467
></DIV
468
><DIV
469
CLASS="SECT2"
470
><H2
471
CLASS="SECT2"
472
><A
473
NAME="CONCEPTS.TERMINOLOGY.CDL">CDL</H2
474
><P
475
>The configuration tools require information about the various options
476
provided by each package, their consequences and constraints, and
477
other properties such as the location of on-line documentation. This
478
information has to be provided in the form of <SPAN
479
CLASS="APPLICATION"
480
>CDL</SPAN
481
> scripts. CDL
482
is short for Component Definition Language, and is specifically
483
designed as a way of describing configuration options.</P
484
><P
485
>A typical package contains the following:</P
486
><P
487
></P
488
><OL
489
TYPE="1"
490
><LI
491
><P
492
>Some number of source files which will end up in a library. The
493
application code will be linked with this library to produce an
494
executable. Some source files may serve other purposes, for example to
495
provide a linker script.</P
496
></LI
497
><LI
498
><P
499
>Exported header files which define the interface provided by the
500
package. </P
501
></LI
502
><LI
503
><P
504
>On-line documentation, for example reference pages for each exported
505
function. </P
506
></LI
507
><LI
508
><P
509
>Some number of test cases, shipped in source format, allowing users to
510
check that the package is working as expected on their particular
511
hardware and in their specific configuration.</P
512
></LI
513
><LI
514
><P
515
>One or more <SPAN
516
CLASS="APPLICATION"
517
>CDL</SPAN
518
> scripts describing the package to the configuration
519
system.</P
520
></LI
521
></OL
522
><P
523
>Not all packages need to contain all of these. For example some
524
packages such as device drivers may not provide a new interface,
525
instead they just provide another implementation of an existing
526
interface. However all packages must contain a <SPAN
527
CLASS="APPLICATION"
528
>CDL</SPAN
529
> script that
530
describes the package to the configuration tools.</P
531
></DIV
532
><DIV
533
CLASS="SECT2"
534
><H2
535
CLASS="SECT2"
536
><A
537
NAME="CONCEPTS.TERMINOLOGY.REPO">Component Repository</H2
538
><P
539
>All <SPAN
540
CLASS="APPLICATION"
541
>eCos</SPAN
542
> installations include a component repository. This is a
543
directory structure where all the packages get installed. The
544
component framework comes with an administration tool that allows new
545
packages or new versions of a package to be installed, old packages to
546
be removed, and so on. The component repository includes a simple
547
database, maintained by the administration tool, which contains
548
details of the various packages.</P
549
><P
550
>Generally application developers do not need to modify anything inside
551
the component repository, except by means of the administration tool.
552
Instead their work involves separate build and install trees. This
553
allows the component repository to be treated as a read-only resource
554
that can be shared by multiple projects and multiple users. Component
555
writers modifying one of the packages do need to manipulate files in
556
the component repository.</P
557
></DIV
558
></DIV
559
></DIV
560
><DIV
561
CLASS="NAVFOOTER"
562
><HR
563
ALIGN="LEFT"
564
WIDTH="100%"><TABLE
565
SUMMARY="Footer navigation table"
566
WIDTH="100%"
567
BORDER="0"
568
CELLPADDING="0"
569
CELLSPACING="0"
570
><TR
571
><TD
572
WIDTH="33%"
573
ALIGN="left"
574
VALIGN="top"
575
><A
576
HREF="cdl-guide.html"
577
ACCESSKEY="P"
578
>Prev</A
579
></TD
580
><TD
581
WIDTH="34%"
582
ALIGN="center"
583
VALIGN="top"
584
><A
585
HREF="cdl-guide.html"
586
ACCESSKEY="H"
587
>Home</A
588
></TD
589
><TD
590
WIDTH="33%"
591
ALIGN="right"
592
VALIGN="top"
593
><A
594
HREF="overview.configurability.html"
595
ACCESSKEY="N"
596
>Next</A
597
></TD
598
></TR
599
><TR
600
><TD
601
WIDTH="33%"
602
ALIGN="left"
603
VALIGN="top"
604
>The <SPAN
605
CLASS="APPLICATION"
606
>eCos</SPAN
607
> Component Writer's Guide</TD
608
><TD
609
WIDTH="34%"
610
ALIGN="center"
611
VALIGN="top"
612
>&nbsp;</TD
613
><TD
614
WIDTH="33%"
615
ALIGN="right"
616
VALIGN="top"
617
>Why Configurability?</TD
618
></TR
619
></TABLE
620
></DIV
621
></BODY
622
></HTML
623
>

powered by: WebSVN 2.1.0

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