+++ /dev/null
-<!-- Copyright (C) 2003 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 is obtained from the copyright holder. -->
-<HTML
-><HEAD
-><TITLE
->Overview</TITLE
-><meta name="MSSmartTagsPreventParsing" content="TRUE">
-<META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
-"><LINK
-REL="HOME"
-TITLE="The eCos Component Writer's Guide"
-HREF="cdl-guide.html"><LINK
-REL="PREVIOUS"
-TITLE="The eCos Component Writer's Guide"
-HREF="cdl-guide.html"><LINK
-REL="NEXT"
-TITLE="Why Configurability?"
-HREF="overview.configurability.html"></HEAD
-><BODY
-CLASS="CHAPTER"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="NAVHEADER"
-><TABLE
-SUMMARY="Header navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TH
-COLSPAN="3"
-ALIGN="center"
->The <SPAN
-CLASS="APPLICATION"
->eCos</SPAN
-> Component Writer's Guide</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="bottom"
-><A
-HREF="cdl-guide.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="80%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="bottom"
-><A
-HREF="overview.configurability.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="CHAPTER"
-><H1
-><A
-NAME="OVERVIEW">Chapter 1. Overview</H1
-><DIV
-CLASS="TOC"
-><DL
-><DT
-><B
->Table of Contents</B
-></DT
-><DT
-><A
-HREF="overview.html#OVERVIEW.TERMINOLOGY"
->Terminology</A
-></DT
-><DT
-><A
-HREF="overview.configurability.html"
->Why Configurability?</A
-></DT
-><DT
-><A
-HREF="overview.approaches.html"
->Approaches to Configurability</A
-></DT
-><DT
-><A
-HREF="overview.degress.html"
->Degrees of Configurability</A
-></DT
-><DT
-><A
-HREF="overview.warning.html"
->Warnings</A
-></DT
-></DL
-></DIV
-><P
-><SPAN
-CLASS="APPLICATION"
->eCos</SPAN
-> was designed from the very beginning as a configurable
-component architecture. The core <SPAN
-CLASS="APPLICATION"
->eCos</SPAN
-> 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, <SPAN
-CLASS="APPLICATION"
->eCos</SPAN
-> 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.</P
-><DIV
-CLASS="SECT1"
-><H1
-CLASS="SECT1"
-><A
-NAME="OVERVIEW.TERMINOLOGY">Terminology</H1
-><P
->The <SPAN
-CLASS="APPLICATION"
->eCos</SPAN
-> component architecture involves a number of key concepts.</P
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="CONCEPTS.TERMINOLOGY.FRAMEWORK">Component Framework</H2
-><P
->The phrase <SPAN
-CLASS="phrase"
-><SPAN
-CLASS="PHRASE"
->component framework</SPAN
-></SPAN
-> is used to describe
-the collection of tools that allow users to configure a system and
-administer a component repository. This includes the <SPAN
-CLASS="APPLICATION"
->ecosconfig</SPAN
-> 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 <SPAN
-CLASS="APPLICATION"
->CDL</SPAN
-> library.</P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="CONCEPTS.TERMINOLOGY.OPTION">Configuration Option</H2
-><P
->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
-<TT
-CLASS="FUNCTION"
->strtok</TT
-> gets inlined. They can also control quite
-large amounts of code, for example whether or not the
-<TT
-CLASS="FUNCTION"
->printf</TT
-> supports floating point conversions.</P
-><P
->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.</P
-><P
->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.</P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="CONCEPTS.TERMINOLOGY.COMPONENT">Component</H2
-><P
->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.</P
-><P
->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 <SPAN
-CLASS="APPLICATION"
->eCos</SPAN
-> 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.</P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="CONCEPTS.TERMINOLOGY.PACKAGE">Package</H2
-><P
->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 <SPAN
-CLASS="APPLICATION"
->eCos</SPAN
-> 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.</P
-><P
->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.</P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="CONCEPTS.TERMINOLOGY.CONFIGURATION">Configuration</H2
-><P
->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 <TT
-CLASS="FILENAME"
->ecos.ecc</TT
->), manipulate a
-configuration, and use a configuration to generate a build tree prior
-to building <SPAN
-CLASS="APPLICATION"
->eCos</SPAN
-> 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. </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="CONCEPTS.TERMINOLOGY.TARGET">Target</H2
-><P
->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.</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 µ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… 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"
-> </TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->Why Configurability?</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
projects / karo-tx-redboot.git / blobdiff