eCos was designed from the very beginning as a configurable component architecture. The core eCos system consists of a number of different components such as the kernel, the C library, an infrastructure package. Each of these provides a large number of configuration options, allowing application developers to build a system that matches the requirements of their particular application. To manage the potential complexity of multiple components and lots of configuration options, eCos comes with a component framework: a collection of tools specifically designed to support configuring multiple components. Furthermore this component framework is extensible, allowing additional components to be added to the system at any time.
The eCos component architecture involves a number of key concepts.
The phrase component framework is used to describe the collection of tools that allow users to configure a system and administer a component repository. This includes the ecosconfig command line tool, the graphical configuration tool, and the package administration tool. Both the command line and graphical tools are based on a single underlying library, the CDL library.
The option is the basic unit of configurability. Typically each option
corresponds to a single choice that a user can make. For example there
is an option to control whether or not assertions are enabled, and the
kernel provides an option corresponding to the number of scheduling
priority levels in the system. Options can control very small amounts
of code such as whether or not the C library's
strtok gets inlined. They can also control quite
large amounts of code, for example whether or not the
printf supports floating point conversions.
Many options are straightforward, and the user only gets to choose whether the option is enabled or disabled. Some options are more complicated, for example the number of scheduling priority levels is a number that should be within a certain range. Options should always start off with a sensible default setting, so that it is not necessary for users to make hundreds of decisions before any work can start on developing the application. Once the application is running the various configuration options can be used to tune the system for the specific needs of the application.
The component framework allows for options that are not directly user-modifiable. Consider the case of processor endianness: some processors are always big-endian or always little-endian, while with other processors there is a choice. Depending on the user's choice of target hardware, endianness may or may not be user-modifiable.
A component is a unit of functionality such as a particular kernel scheduler or a device driver for a specific device. A component is also a configuration option in that users may want to enable or disable all the functionality in a component. For example, if a particular device on the target hardware is not going to be used by the application, directly or indirectly, then there is no point in having a device driver for it. Furthermore disabling the device driver should reduce the memory requirements for both code and data.
Components may contain further configuration options. In the case of a device driver, there may be options to control the exact behavior of that driver. These will of course be irrelevant if the driver as a whole is disabled. More generally options and components live in a hierarchy, where any component can contain options specific to that component and further sub-components. It is possible to view the entire eCos kernel as one big component, containing sub-components for scheduling, exception handling, synchronization primitives, and so on. The synchronization primitives component can contain further sub-components for mutexes, semaphores, condition variables, event flags, and so on. The mutex component can contain configuration options for issues like priority inversion support.
A package is a special type of component. Specifically, a package is the unit of distribution of components. It is possible to create a distribution file for a package containing all of the source code, header files, documentation, and other relevant files. This distribution file can then be installed using the appropriate tool. Afterwards it is possible to uninstall that package, or to install a later version. The core eCos distribution comes with a number of packages such as the kernel and the infrastructure. Other packages such as network stacks can come from various different sources and can be installed alongside the core distribution.
Packages can be enabled or disabled, but the user experience is a little bit different. Generally it makes no sense for the tools to load the details of every single package that has been installed. For example, if the target hardware uses an ARM processor then there is no point in loading the HAL packages for other architectures and displaying choices to the user which are not relevant. Therefore enabling a package means loading its configuration data into the appropriate tool, and disabling a package is an unload operation. In addition, packages are not just enabled or disabled: it is also possible to select the particular version of a package that should be used.
A configuration is a collection of user choices. The various tools that make up the component framework deal with entire configurations. Users can create a new configuration, output a savefile (by default ecos.ecc), manipulate a configuration, and use a configuration to generate a build tree prior to building eCos and any other packages that have been selected. A configuration includes details such as which packages have been selected, in addition to finer-grained information such as which options in those packages have been enabled or disabled by the user.
The target is the specific piece of hardware on which the application is expected to run. This may be an off-the-shelf evaluation board, a piece of custom hardware intended for a specific application, or it could be something like a simulator. One of the steps when creating a new configuration is need to specify the target. The component framework will map this on to a set of packages that are used to populate the configuration, typically HAL and device driver packages, and in addition it may cause certain options to be changed from their default settings to something more appropriate for the specified target.
A template is a partial configuration, aimed at providing users with an appropriate starting point. eCos is shipped with a small number of templates, which correspond closely to common ways of using the system. There is a minimal template which provides very little functionality, just enough to bootstrap the hardware and then jump directly to application code. The default template adds additional functionality, for example it causes the kernel and C library packages to be loaded as well. The uitron template adds further functionality in the form of a µITRON compatibility layer. Creating a new configuration typically involves specifying a template as well as a target, resulting in a configuration that can be built and linked with the application code and that will run on the actual hardware. It is then possible to fine-tune configuration options to produce something that better matches the specific requirements of the application.
The component framework needs a certain amount of information about each option. For example it needs to know what the legal values are, what the default should be, where to find the on-line documentation if the user needs to consult that in order to make a decision, and so on. These are all properties of the option. Every option (including components and packages) consists of a name and a set of properties.
Choices must have consequences. For an eCos configuration the main end product is a library that can be linked with application code, so the consequences of a user choice must affect the build process. This happens in two main ways. First, options can affect which files get built and end up in the library. Second, details of the current option settings get written into various configuration header files using C preprocessor #define directives, and package source code can #include these configuration headers and adapt accordingly. This allows options to affect a package at a very fine grain, at the level of individual lines in a source file if desired. There may be other consequences as well, for example there are options to control the compiler flags that get used during the build process.
Configuration choices are not independent. The C library can provide
thread-safe implementations of functions like
rand, but only if the kernel provides support for
per-thread data. This is a constraint: the C library option has a
requirement on the kernel. A typical configuration involves a
considerable number of constraints, of varying complexity: many
constraints are straightforward, option A requires
option B, or option C precludes
option D. Other constraints can be more
complicated, for example option E may require the
presence of a kernel scheduler but does not care whether it is the
bitmap scheduler, the mlqueue scheduler, or something else.
Another type of constraint involves the values that can be used for certain options. For example there is a kernel option related to the number of scheduling levels, and there is a legal values constraint on this option: specifying zero or a negative number for the number of scheduling levels makes no sense.
As the user manipulates options it is possible to end up with an invalid configuration, where one or more constraints are not satisfied. For example if kernel per-thread data is disabled but the C library's thread-safety options are left enabled then there are unsatisfied constraints, also known as conflicts. Such conflicts will be reported by the configuration tools. The presence of conflicts does not prevent users from attempting to build eCos, but the consequences are undefined: there may be compile-time failures, there may be link-time failures, the application may completely fail to run, or the application may run most of the time but once in a while there will be a strange failure… Typically users will want to resolve all conflicts before continuing.
To make things easier for the user, the configuration tools contain an inference engine. This can examine a conflict in a particular configuration and try to figure out some way of resolving the conflict. Depending on the particular tool being used, the inference engine may get invoked automatically at certain times or the user may need to invoke it explicitly. Also depending on the tool, the inference engine may apply any solutions it finds automatically or it may request user confirmation.
The configuration tools require information about the various options provided by each package, their consequences and constraints, and other properties such as the location of on-line documentation. This information has to be provided in the form of CDL scripts. CDL is short for Component Definition Language, and is specifically designed as a way of describing configuration options.
A typical package contains the following:
Some number of source files which will end up in a library. The application code will be linked with this library to produce an executable. Some source files may serve other purposes, for example to provide a linker script.
Exported header files which define the interface provided by the package.
On-line documentation, for example reference pages for each exported function.
Some number of test cases, shipped in source format, allowing users to check that the package is working as expected on their particular hardware and in their specific configuration.
One or more CDL scripts describing the package to the configuration system.
Not all packages need to contain all of these. For example some packages such as device drivers may not provide a new interface, instead they just provide another implementation of an existing interface. However all packages must contain a CDL script that describes the package to the configuration tools.
All eCos installations include a component repository. This is a directory structure where all the packages get installed. The component framework comes with an administration tool that allows new packages or new versions of a package to be installed, old packages to be removed, and so on. The component repository includes a simple database, maintained by the administration tool, which contains details of the various packages.
Generally application developers do not need to modify anything inside the component repository, except by means of the administration tool. Instead their work involves separate build and install trees. This allows the component repository to be treated as a read-only resource that can be shared by multiple projects and multiple users. Component writers modifying one of the packages do need to manipulate files in the component repository.