concepts.sgml

ecos实时嵌入式操作系统

<!-- {{{ Banner                 -->

<!-- =============================================================== -->
<!--                                                                 -->
<!--     concepts.sgml                                               -->
<!--                                                                 -->
<!--     Introductory chapter.                                       -->
<!--                                                                 -->
<!-- =============================================================== -->
<!-- ####COPYRIGHTBEGIN####                                          -->
<!--                                                                 -->
<!-- =============================================================== -->
<!-- Copyright (C) 2000, 2001, 2002 Red Hat, Inc.                    -->
<!--                                                                 -->
<!-- This material may be distributed only subject to the terms      -->
<!-- and conditions set forth in the Open Publication License, v1.0  -->
<!-- or later (the latest version is presently available at          -->
<!-- http://www.opencontent.org/openpub/)                            -->
<!-- Distribution of the work or derivative of the work in any       -->
<!-- standard (paper) book form is prohibited unless prior           -->
<!-- permission obtained from the copyright holder                   -->
<!-- =============================================================== -->
<!--                                                                 -->      
<!-- ####COPYRIGHTEND####                                            -->
<!-- =============================================================== -->
<!-- #####DESCRIPTIONBEGIN####                                       -->
<!--                                                                 -->
<!-- Author(s):   bartv                                              -->
<!-- Contact(s):  bartv                                              -->
<!-- Date:        2000/02/06                                         -->
<!-- Version:     0.01                                               -->
<!--                                                                 -->
<!-- ####DESCRIPTIONEND####                                          -->
<!-- =============================================================== -->

<!-- }}} -->

<chapter id="overview">
<title>Overview</title>

<!-- {{{ Introit                --> 

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

<!-- }}} -->
<!-- {{{ Terminology            --> 

<sect1 id="overview.terminology">
<title>Terminology</title>
<para>
The &eCos; component architecture involves a number of key concepts.
</para>

<!-- {{{ Component Framework    -->

<sect2 id="concepts.terminology.framework">
<title>Component Framework</title>

<para>
The phrase <phrase>component framework</phrase> is used to describe
the collection of tools that allow users to configure a system and
administer a component repository. This includes the <application
class="software">ecosconfig</application> 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.
</para>

</sect2>

<!-- }}} -->
<!-- {{{ Option                 -->

<sect2 id="concepts.terminology.option">
<title>Configuration Option</title>
<para>
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
<function>strtok</function> gets inlined. They can also control quite
large amounts of code, for example whether or not the
<function>printf</function> supports floating point conversions.
</para>
<para>
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.
</para>
<para>
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.
</para>
</sect2>

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

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

<!-- }}} -->
<!-- {{{ Package                -->

<sect2 id="concepts.terminology.package">
<title>Package</title>
<para>
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.
</para>
<para>
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.
</para>
</sect2>

<!-- }}} -->
<!-- {{{ Configuration          -->

<sect2 id="concepts.terminology.configuration">
<title>Configuration</title>
<para>
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 <filename>ecos.ecc</filename>), 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. 
</para>
</sect2>

<!-- }}} -->
<!-- {{{ Target                 -->

<sect2 id="concepts.terminology.target">
<title>Target</title>
<para>
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.
</para>
</sect2>

<!-- }}} -->
<!-- {{{ Template               -->

<sect2 id="concepts.terminology.template">
<title>Template</title>
<para>
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 &uITRON; 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.
</para>
</sect2>

<!-- }}} -->
<!-- {{{ Properties             -->

<sect2 id="concepts.terminology.properties">
<title>Properties</title>
<para>
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.
</para>
</sect2>

<!-- }}} -->
<!-- {{{ Consequences           -->

<sect2 id="concepts.terminology.consequences">
<title>Consequences</title>
<para>
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 <literal>#define</literal> directives, and package source
code can <literal>#include</literal> 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