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.
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.
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).
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.
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.
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 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:
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 are relationships between CDL items. There are three types of expression in CDL:
Each configuration item has a set of properties. The following table describes the most commonly used:
A complete description of properties is contained in the CDL Writer's Guide.
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.
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:
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 | ||
|---|---|---|