--- /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
+>Why Configurability?</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="UP"
+TITLE="Overview"
+HREF="overview.html"><LINK
+REL="PREVIOUS"
+TITLE="Overview"
+HREF="overview.html"><LINK
+REL="NEXT"
+TITLE="Approaches to Configurability"
+HREF="overview.approaches.html"></HEAD
+><BODY
+CLASS="SECT1"
+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="overview.html"
+ACCESSKEY="P"
+>Prev</A
+></TD
+><TD
+WIDTH="80%"
+ALIGN="center"
+VALIGN="bottom"
+>Chapter 1. Overview</TD
+><TD
+WIDTH="10%"
+ALIGN="right"
+VALIGN="bottom"
+><A
+HREF="overview.approaches.html"
+ACCESSKEY="N"
+>Next</A
+></TD
+></TR
+></TABLE
+><HR
+ALIGN="LEFT"
+WIDTH="100%"></DIV
+><DIV
+CLASS="SECT1"
+><H1
+CLASS="SECT1"
+><A
+NAME="OVERVIEW.CONFIGURABILITY">Why Configurability?</H1
+><P
+>The <SPAN
+CLASS="APPLICATION"
+>eCos</SPAN
+> 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.</P
+><P
+>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.</P
+><P
+>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.</P
+><P
+>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.</P
+><P
+>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 — 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.</P
+></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="overview.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.approaches.html"
+ACCESSKEY="N"
+>Next</A
+></TD
+></TR
+><TR
+><TD
+WIDTH="33%"
+ALIGN="left"
+VALIGN="top"
+>Overview</TD
+><TD
+WIDTH="34%"
+ALIGN="center"
+VALIGN="top"
+><A
+HREF="overview.html"
+ACCESSKEY="U"
+>Up</A
+></TD
+><TD
+WIDTH="33%"
+ALIGN="right"
+VALIGN="top"
+>Approaches to Configurability</TD
+></TR
+></TABLE
+></DIV
+></BODY
+></HTML
+>
\ No newline at end of file
projects / karo-tx-redboot.git / blobdiff