CDL Concepts
To Contents | To previous page | To next page

## CDL Concepts

### 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 CDL Writer's Guide.

### 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.

### 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).

### 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.

### 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.

### 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) is provided by Red Hat: 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 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.

### 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 preprocessor 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 placeholders 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.

#### Expressions

Expressions are relationships between CDL items. There are three types of expression in CDL:

CDL Expressions

Expression Type | Result | Common Use [see Table 2]
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

#### Properties

Each configuration item has a set of properties. The following table describes the most commonly used:

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 CDL Writer's Guide.

#### 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.

### 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.

### 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.

CDL Concepts
To Contents | To previous page | To next page