--- /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