1 <!-- Copyright (C) 2003 Red Hat, Inc. -->
2 <!-- This material may be distributed only subject to the terms -->
3 <!-- and conditions set forth in the Open Publication License, v1.0 -->
4 <!-- or later (the latest version is presently available at -->
5 <!-- http://www.opencontent.org/openpub/). -->
6 <!-- Distribution of the work or derivative of the work in any -->
7 <!-- standard (paper) book form is prohibited unless prior -->
8 <!-- permission is obtained from the copyright holder. -->
12 >Why Configurability?</TITLE
13 ><meta name="MSSmartTagsPreventParsing" content="TRUE">
16 CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
19 TITLE="The eCos Component Writer's Guide"
20 HREF="cdl-guide.html"><LINK
23 HREF="overview.html"><LINK
26 HREF="overview.html"><LINK
28 TITLE="Approaches to Configurability"
29 HREF="overview.approaches.html"></HEAD
40 SUMMARY="Header navigation table"
52 > Component Writer's Guide</TH
68 >Chapter 1. Overview</TD
74 HREF="overview.approaches.html"
88 NAME="OVERVIEW.CONFIGURABILITY">Why Configurability?</H1
93 > component framework places a great deal of emphasis on
94 configurability. The fundamental goal is to allow large parts of
95 embedded applications to be constructed from re-usable software
96 components, which does not a priori require that those components be
97 highly configurable. However embedded application development often
98 involves some serious constraints.</P
100 >Many embedded applications have to work with very little memory, to
101 keep down manufacturing costs. The final application image that will
102 get blown into EPROM's or used to manufacture ROMs should contain only
103 the code that is absolutely necessary for the application to work, and
104 nothing else. If a few tens of kilobytes are added unnecessarily to a
105 typical desktop application then this is regrettable, but is quite
106 likely to go unnoticed. If an embedded application does not fit on the
107 target hardware then the problem is much more serious. The component
108 framework must allow users to configure the components so that any
109 unnecessary functionality gets removed.</P
111 >Many embedded applications need deterministic behavior so that they
112 can meet real-time requirements. Such deterministic behavior can
113 often be provided, but at a cost in terms of code size, slower
114 algorithms, and so on. Other applications have no such real-time
115 requirements, or only for a small part of the overall system, and the
116 bulk of the system should not suffer any penalties. Again the
117 component framework must allow the users control over the timing
118 behavior of components.</P
120 >Embedded systems tend to be difficult to debug. Even when it is
121 possible to get information out of the target hardware by means other
122 than flashing an LED, the more interesting debugging problems are
123 likely to be timing-related and hence very hard to reproduce and track
124 down. The re-usable components can provide debugging assistance in
125 various ways. They can provide functionality that can be exploited by
126 source level debuggers such as gdb, for example per-thread debugging
127 information. They can also contain various assertions so that problems
128 can be detected early on, tracing mechanisms to figure out what
129 happened before the assertion failure, and so on. Of course all of
130 these involve overheads, especially code size, and affect the timing.
131 Allowing users to control which debugging features are enabled for any
132 given application build is very desirable.</P
134 >However, although it is desirable for re-usable components to provide
135 appropriate configuration options this is not required. It is possible
136 to produce a package which does not provide a single configuration
137 option — although the user still gets to choose
138 whether or not to use the package. In such cases it is still necessary
139 to provide a minimal CDL script, but its main purpose would be to
140 integrate the package with the component framework's build system.</P
147 SUMMARY="Footer navigation table"
167 HREF="cdl-guide.html"
176 HREF="overview.approaches.html"
200 >Approaches to Configurability</TD
projects / karo-tx-redboot.git / blob