Embedded systems have an amazing range of requirements, from 4 bit controllers up to large radar arrays with a thousand or so top of the range processors. Even if we limit the eCos target market to deeply embedded devices and to processors for which a gcc port is available, it is not possible to write a single system which meets everybody's requirements. The conventional approach forces application developers to adapt their software so that it works within the limitations of the operating system. The eCos approach is to provide a whole range of options and let the developer configure a system that best matches the needs of the application. Typical configuration options include the type of scheduler and the number of priority levels. The current release of the system has over 200 such options, and plenty more will be added as the system evolves.

Code and data size are vitally important for many embedded applications, so configurability must be achieved without adding any overheads. Some of it can be done at link time, but for maximum benefit most of it happens at compile time. It is possible for a configuration option to affect a single line of code, when this is appropriate. On the other hand a single configuration option might control the presence or absence of a complete TCP/IP stack. For system code written in C or C++ the main mechanism that is employed is C preprocessor #ifdef statements, which will be familiar to most embedded application developers.

Using #ifdef statements to provide a small number of configuration options is of course not very original. The critical problem is that configuration options are not independent: for example, changing a kernel option may affect whether or not the C library can provide thread-safe versions of various routines. The key innovation in eCos is that configuration options are treated as data items in their own right, complete with descriptions of all the dependencies between the various options. There is a graphical configuration tool which allows users to conveniently manipulate the various options, understand the various interactions, and check that the resulting configuration is valid.

The configuration framework also serves to componentize the system into different packages. The core system consists of a number of different packages including the kernel, the C library, and the math library. It is possible to enable or disable entire packages, as well as to manipulate configuration options within these packages. It is also possible to add new packages to the system, for example a TCP/IP stack. The key point is that these new packages can specify dependencies on other parts of the system, for example the TCP/IP stack could specify that it needs per-thread data support. The same technology that makes configurability work in the core system allows new packages to be added to the system and readily incorporated into an application. We expect large numbers of these packages to become available over time, and already there are software vendors who want to turn their existing software into eCos packages. We expect that many contributions from the open source community will take the form of ports of existing software or of completely new packages.

The eCos configuration system does not affect how you develop your own application code. It is not necessary to write your application in any special language, or to provide lots of configuration options in your own code, or to use a special development environment. The main output from the configuration system is a library that gets linked with your application code in the usual manner.