overview.html

有关ecos2。0介绍了实时嵌入式的结构以及线程调度的实现和内存的管理等

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.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="CONCEPTS.TERMINOLOGY.TEMPLATE">Template</H2
><P
>A template is a partial configuration, aimed at providing users with
an appropriate starting point. <SPAN
CLASS="APPLICATION"
>eCos</SPAN
> 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 &micro;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.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="CONCEPTS.TERMINOLOGY.PROPERTIES">Properties</H2
><P
>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.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="CONCEPTS.TERMINOLOGY.CONSEQUENCES">Consequences</H2
><P
>Choices must have consequences. For an <SPAN
CLASS="APPLICATION"
>eCos</SPAN
> 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 <TT
CLASS="LITERAL"
>#define</TT
> directives, and package source
code can <TT
CLASS="LITERAL"
>#include</TT
> 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.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="CONCEPTS.TERMINOLOGY.CONSTRAINTS">Constraints</H2
><P
>Configuration choices are not independent. The C library can provide
thread-safe implementations of functions like
<TT
CLASS="FUNCTION"
>rand</TT
>, 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 <TT
CLASS="LITERAL"
>A</TT
> requires
option <TT
CLASS="LITERAL"
>B</TT
>, or option <TT
CLASS="LITERAL"
>C</TT
> precludes
option <TT
CLASS="LITERAL"
>D</TT
>. Other constraints can be more
complicated, for example option <TT
CLASS="LITERAL"
>E</TT
> may require the
presence of a kernel scheduler but does not care whether it is the
bitmap scheduler, the mlqueue scheduler, or something else.</P
><P
>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.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="CONCEPTS.TERMINOLOGY.CONFLICTS">Conflicts</H2
><P
>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 <SPAN
CLASS="APPLICATION"
>eCos</SPAN
>, 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&#8230; Typically users will want to resolve
all conflicts before continuing.</P
><P
>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.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="CONCEPTS.TERMINOLOGY.CDL">CDL</H2
><P
>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 <SPAN
CLASS="APPLICATION"
>CDL</SPAN
> scripts. CDL
is short for Component Definition Language, and is specifically
designed as a way of describing configuration options.</P
><P
>A typical package contains the following:</P
><P
></P
><OL
TYPE="1"
><LI
><P
>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.</P
></LI
><LI
><P
>Exported header files which define the interface provided by the
package. </P
></LI
><LI
><P
>On-line documentation, for example reference pages for each exported
function. </P
></LI
><LI
><P
>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.</P
></LI
><LI
><P
>One or more <SPAN
CLASS="APPLICATION"
>CDL</SPAN
> scripts describing the package to the configuration
system.</P
></LI
></OL
><P
>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 <SPAN
CLASS="APPLICATION"
>CDL</SPAN
> script that
describes the package to the configuration tools.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="CONCEPTS.TERMINOLOGY.REPO">Component Repository</H2
><P
>All <SPAN
CLASS="APPLICATION"
>eCos</SPAN
> 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.</P
><P
>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.</P
></DIV
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="cdl-guide.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="cdl-guide.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="overview.configurability.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>The <SPAN
CLASS="APPLICATION"
>eCos</SPAN
> Component Writer's Guide</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
>&nbsp;</TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Why Configurability?</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>