| Chapter 22. CDL Concepts | ||
|---|---|---|
 | Part IV. eCos Programming Concepts and Techniques |  |
Chapter 22. CDL Concepts
Table of Contents
22.1. About this chapter
This chapter serves as a brief introduction to the concepts involved in eCos (Embedded Configurable Operating System). It describes the configuration architecture and the underlying technology to a level required for the embedded systems developer to configure eCos. It does not describe in detail aspects such as how to write reusable components for eCos: this information is given in the Component Writer‚s Guide.
22.1.1. Background
Software solutions for the embedded space place particularly stringent demands on the developer, typically represented as requirements for small memory footprint, high performance and robustness. These demands are addressed in eCos by providing the ability to perform compile-time specialization: the developer can tailor the operating system to suit the needs of the application. In order to make this process manageable, eCos is built in the context of a Configuration Infrastructure: a set of tools including a Configuration Tool and a formal description of the process of configuration by means of a Component Definition Language.
22.1.2. Configurations
eCos is tailored at source level (that is, before compilation or assembly) in order to create an eCos configuration. In concrete terms, an eCos configuration takes the form of a configuration save file (with extension .ecc) and set of files used to build user applications (including, when built, a library file against which the application is linked).
22.2. Component Repository
eCos is shipped in source in the form of a component repository - a directory hierarchy that contains the sources and other files which are used to build a configuration. The component repository can be added to by, for example, downloading from the net.
22.3. Component Definition Language
Part of the component repository is a set of files containing a definition of its structure. The form used for this purpose is the Component Definition Language (CDL). CDL defines the relationships between components and other information used by tools such as the eCos Configuration Tool. CDL is generally formulated by the writers of components: it is not necessary to write or understand CDL in order for the embedded systems developer to construct an eCos configuration.
22.4. Packages
The building blocks of an eCos configuration are called packages. Packages are the units of software distribution. A set of core packages (such as kernel, C library and math library) additional packages provided by eCosCentric (such as C++ library and USB device support): additional third-party packages will be available in future.
A package may exist in one of a number of versions. The default version is the current version. Only one version of a given package may be present in the component repository at any given time.
Packages are organized in a tree hierarchy. Each package is either at the top-level or is the child of another package.
The eCos Package Administration Tool can be used to add or remove packages from the component repository. The eCos Configuration Tool can be used to include or exclude packages from the configuration being built.
22.5. Configuration Items
Configuration items are the
individual entities that form a configuration. Each item
corresponds to the setting of a C pre-processor macro (for
example,
CYGHWR_HAL_ARM_PID_GDB_BAUD).
The code of eCos itself is written to test such pre-processor
macros so as to tailor the code. User code can do
likewise.
Configuration items come in the following flavors:
None: such entities serve only as place holders in the hierarchy, allowing other entities to be grouped more easily.
Boolean entities are the most common flavor; they correspond to units of functionality that can be either enabled or disabled. If the entity is enabled then there will be a #define; code will check the setting using, for example, #ifdef
Data entities encapsulate some arbitrary data. Other properties such as a set or range of legal values can be used to constrain the actual values, for example to an integer or floating point value within a certain range.
Booldata entities combine the attributes of Boolean and Data: they can be enabled or disabled and, if enabled, will hold a data value.
Like packages, configuration items exist in a tree-based hierarchy: each configuration item has a parent which may be another configuration item or a package. Under some conditions (such as when packages are added or removed from a configuration), items may be “re-parented” such that their position in the tree changes.
22.5.1. Expressions
Expressions are relationships between CDL items. There are three types of expression in CDL:
Table 22.1. CDL Expressions
| Expression Type | Result | Common Use (see Table 22.2, “Configuration properties”) |
|---|---|---|
| Ordinary | A single value | legal_values property |
| List | A range of values (for example “1 to 10”) | legal_values property |
| Goal | True or False | requires and active_if properties |
22.5.2. Properties
Each configuration item has a set of properties. The following table describes the most commonly used:
Table 22.2. Configuration properties
| Property | Use |
|---|---|
| Flavor | The “type” of the item, as described above |
| Enabled | Whether the item is enabled |
| Current_value | The current value of the item |
| Default_value | An ordinary expression defining the default value of the item |
| Legal_values | A list expression defining the values the item may hold (for example, 1 to10) |
| Active_if | A goal expression denoting the requirement for this item to be active (see below: Inactive Items) |
| Requires | A goal expression denoting requirements this item places on others (see below: Conflicts) |
| Calculated | Whether the item as non-modifiable |
| Macro | The corresponding C pre-processor macro |
| File | The C header file in which the macro is defined |
| URL | The URL of a documentation page describing the item |
| Hardware | Indicates that a particular package is related to specific hardware |
A complete description of properties is contained in the Component Writer‚s Guide.
22.5.3. Inactive Items
Descendants of an item that is disabled are inactive: their values may not be changed. Items may also become inactive if an active_if expression is used to make the item dependent on an expression involving other items.
22.6. Conflicts
Not all settings of configuration items will lead to a coherent configuration; for example, the use of a timeout facility might require the existence of timer support, so if the one is required the other cannot be removed. Coherence is policed by means of consistency rules (in particular, the goal expressions that appear as CDL items requires and active_if attributes [see above]). A violation of consistency rules creates a conflict, which must be resolved in order to ensure a consistent configuration. Conflict resolution can be performed manually or with the assistance of the eCos tools. Conflicts come in the following flavors:
An unresolved conflict means that there is a reference to an entity that is not yet in the current configuration
An illegal value conflict is caused when a configuration item is set to a value that is not permitted (that is, a legal_values goal expression is failing)
An evaluation exception conflict is caused when the evaluation of an expression would fail (for example, because of a division by zero)
An unsatisfied goal conflict is caused by a failing requires goal expression
A bad data conflict arises only rarely, and corresponds to badly constructed CDL. Such a conflict can only be resolved by reference to the CDL writer.
22.7. Templates
A template is a saved configuration - that is, a set of packages and configuration item settings. Templates are provided with eCos to allow you to get started quickly by instantiating (copying) a saved configuration corresponding to one of a number of common scenarios; for example, a basic eCos configuration template is supplied that contains the infrastructure, kernel, C and math libraries, plus their support packages.
| |  | |
| Part IV. eCos Programming Concepts and Techniques |  | Chapter 23. The Component Repository and Working Directories |
| 2024-12-10 | Open Publication License |