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.