concepts.sgml

ecos实时嵌入式操作系统

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.
</para>
</sect2>

<!-- }}} -->
<!-- {{{ Constraints            -->

<sect2 id="concepts.terminology.constraints">
<title>Constraints</title>
<para>
Configuration choices are not independent. The C library can provide
thread-safe implementations of functions like
<function>rand</function>, 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 <literal>A</literal> requires
option <literal>B</literal>, or option <literal>C</literal> precludes
option <literal>D</literal>. Other constraints can be more
complicated, for example option <literal>E</literal> may require the
presence of a kernel scheduler but does not care whether it is the
bitmap scheduler, the mlqueue scheduler, or something else.
</para>
<para>
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.
</para>
</sect2>

<!-- }}} -->
<!-- {{{ Conflicts              -->

<sect2 id="concepts.terminology.conflicts">
<title>Conflicts</title>
<para>
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&hellip; Typically users will want to resolve
all conflicts before continuing.
</para>
<para>
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.
</para>
</sect2>

<!-- }}} -->
<!-- {{{ CDL                    -->

<sect2 id="concepts.terminology.cdl">
<title>CDL</title>
<para>
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.
</para>
<para>
A typical package contains the following:
</para>
<orderedlist>
<listitem><para>
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.
</para></listitem>
<listitem><para>
Exported header files which define the interface provided by the
package. 
</para></listitem>
<listitem><para>
On-line documentation, for example reference pages for each exported
function. 
</para></listitem>
<listitem><para>
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.
</para></listitem>
<listitem><para>
One or more &CDL; scripts describing the package to the configuration
system.
</para></listitem>
</orderedlist>
<para>
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.
</para>
</sect2>

<!-- }}} -->
<!-- {{{ Component Repository   -->

<sect2 id="concepts.terminology.repo">
<title>Component Repository</title>
<para>
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.
</para>
<para>
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.
</para>
</sect2>

<!-- }}} -->

</sect1>

<!-- }}} -->
<!-- {{{ Why configurability ?  --> 

<sect1 id="overview.configurability">
<title>Why Configurability?</title>
<para>
The &eCos; component framework places a great deal of emphasis on
configurability. The fundamental goal is to allow large parts of
embedded applications to be constructed from re-usable software
components, which does not a priori require that those components be
highly configurable. However embedded application development often
involves some serious constraints.
</para>
<para>
Many embedded applications have to work with very little memory, to
keep down manufacturing costs. The final application image that will
get blown into EPROM's or used to manufacture ROMs should contain only
the code that is absolutely necessary for the application to work, and
nothing else. If a few tens of kilobytes are added unnecessarily to a
typical desktop application then this is regrettable, but is quite
likely to go unnoticed. If an embedded application does not fit on the
target hardware then the problem is much more serious. The component
framework must allow users to configure the components so that any
unnecessary functionality gets removed.
</para>
<para>
Many embedded applications need deterministic behavior so that they
can meet real-time requirements. Such deterministic behavior can
often be provided, but at a cost in terms of code size, slower
algorithms, and so on. Other applications have no such real-time
requirements, or only for a small part of the overall system, and the
bulk of the system should not suffer any penalties. Again the
component framework must allow the users control over the timing
behavior of components.
</para>
<para>
Embedded systems tend to be difficult to debug. Even when it is
possible to get information out of the target hardware by means other
than flashing an LED, the more interesting debugging problems are
likely to be timing-related and hence very hard to reproduce and track
down. The re-usable components can provide debugging assistance in
various ways. They can provide functionality that can be exploited by
source level debuggers such as gdb, for example per-thread debugging
information. They can also contain various assertions so that problems
can be detected early on, tracing mechanisms to figure out what
happened before the assertion failure, and so on. Of course all of
these involve overheads, especially code size, and affect the timing.
Allowing users to control which debugging features are enabled for any
given application build is very desirable.
</para>
<para>
However, although it is desirable for re-usable components to provide
appropriate configuration options this is not required. It is possible
to produce a package which does not provide a single configuration
option&nbsp;&mdash;&nbsp;although the user still gets to choose
whether or not to use the package. In such cases it is still necessary
to provide a minimal CDL script, but its main purpose would be to
integrate the package with the component framework's build system.
</para>
</sect1>

<!-- }}} -->
<!-- {{{ Approaches             --> 

<sect1 id="overview.approaches">
<title>Approaches to Configurability</title>

<para>
The purpose of configurability is to control the behavior of
components. A scheduler component may or may not support time slicing;
it may or may not support multiple priorities; it may or may not
perform error checking on arguments passed to the scheduler routines.
In the context of a desktop application a button widget may contain
some text or it may contain a picture; the text may be displayed in a
variety of fonts; the foreground and background color may vary. When
an application uses a component there must be some way of specifying
the desired behavior. The component writer has no way of knowing in
advance exactly how a particular component will end up being used.
</para>
<para>
One way to control the behavior is at run time. The application
creates an instance of a button object, and then instructs this object
to display either text or a picture. No special effort by the
application developer is required, since a button can always support
all desired behavior. There is of course a major disadvantage in
terms of the size of the final application image: the code that gets
linked with the application has to provide support for all possible
behavior, even if the application does not require it.
</para>
<para>
Another approach is to control the behavior at link-time, typically
by using inheritance in an object-oriented language. The button
library provides an abstract base class <classname>Button</classname>
and derived classes <classname>TextButton</classname> and
<classname>PictureButton</classname>. If an application only uses text
buttons then it will only create objects of type
<classname>TextButton</classname>, and the code for the
<classname>PictureButton</classname> class does not get used. In
many cases this approach works rather well and reduces the final image
size, but there are limitations. The main one is that you can only
have so many derived classes before the system gets unmanageable: a
derived class
<classname>TextButtonUsingABorderWidthOfOnePlusAWhiteBackgroundAndBlackForegroundAndATwelvePointTimesFontAndNoErrorCheckingOrAssertions</classname>
is not particularly sensible as far as most application developers are
concerned.
</para>
<para>
The &eCos; component framework allows the behavior of components to
be controlled at an even earlier time: when the component source code
gets compiled and turned into a library. The button component could
provide options, for example an option that only text buttons need to
be supported. The component gets built and becomes part of a library
intended specifically for the application, and the library will
contain only the code that is required by this application and nothing
else. A different application with different requirements would need
its own version of the library, configured separately.
</para>
<para>
In theory compile-time configurability should give the best possible
results in terms of code size, because it allows code to be controlled
at the individual statement level rather than at the function or
object level. Consider an example more closely related to embedded
systems, a package to support multi-threading. A standard routine
within such a package allows applications to kill threads
asynchronously: the POSIX routine for this is
<function>pthread_cancel</function>; the equivalent routine in &uITRON;
is <function>ter_tsk</function>. These routines themselves tend to
involve a significant amount of code, but that is not the real
problem: other parts of the system require extra code and data for the