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 >Approaches to 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
25 TITLE="Why Configurability?"
26 HREF="overview.configurability.html"><LINK
28 TITLE="Degrees of Configurability"
29 HREF="overview.degress.html"></HEAD
40 SUMMARY="Header navigation table"
52 > Component Writer's Guide</TH
60 HREF="overview.configurability.html"
68 >Chapter 1. Overview</TD
74 HREF="overview.degress.html"
88 NAME="OVERVIEW.APPROACHES">Approaches to Configurability</H1
90 >The purpose of configurability is to control the behavior of
91 components. A scheduler component may or may not support time slicing;
92 it may or may not support multiple priorities; it may or may not
93 perform error checking on arguments passed to the scheduler routines.
94 In the context of a desktop application a button widget may contain
95 some text or it may contain a picture; the text may be displayed in a
96 variety of fonts; the foreground and background color may vary. When
97 an application uses a component there must be some way of specifying
98 the desired behavior. The component writer has no way of knowing in
99 advance exactly how a particular component will end up being used.</P
101 >One way to control the behavior is at run time. The application
102 creates an instance of a button object, and then instructs this object
103 to display either text or a picture. No special effort by the
104 application developer is required, since a button can always support
105 all desired behavior. There is of course a major disadvantage in
106 terms of the size of the final application image: the code that gets
107 linked with the application has to provide support for all possible
108 behavior, even if the application does not require it.</P
110 >Another approach is to control the behavior at link-time, typically
111 by using inheritance in an object-oriented language. The button
112 library provides an abstract base class <TT
116 and derived classes <TT
123 >. If an application only uses text
124 buttons then it will only create objects of type
128 >, and the code for the
132 > class does not get used. In
133 many cases this approach works rather well and reduces the final image
134 size, but there are limitations. The main one is that you can only
135 have so many derived classes before the system gets unmanageable: a
139 >TextButtonUsingABorderWidthOfOnePlusAWhiteBackgroundAndBlackForegroundAndATwelvePointTimesFontAndNoErrorCheckingOrAssertions</TT
141 is not particularly sensible as far as most application developers are
147 > component framework allows the behavior of components to
148 be controlled at an even earlier time: when the component source code
149 gets compiled and turned into a library. The button component could
150 provide options, for example an option that only text buttons need to
151 be supported. The component gets built and becomes part of a library
152 intended specifically for the application, and the library will
153 contain only the code that is required by this application and nothing
154 else. A different application with different requirements would need
155 its own version of the library, configured separately.</P
157 >In theory compile-time configurability should give the best possible
158 results in terms of code size, because it allows code to be controlled
159 at the individual statement level rather than at the function or
160 object level. Consider an example more closely related to embedded
161 systems, a package to support multi-threading. A standard routine
162 within such a package allows applications to kill threads
163 asynchronously: the POSIX routine for this is
167 >; the equivalent routine in µITRON
171 >. These routines themselves tend to
172 involve a significant amount of code, but that is not the real
173 problem: other parts of the system require extra code and data for the
174 kill routine to be able to function correctly. For example if a thread
175 is blocked while waiting on a mutex and is killed off by another
176 thread then the kill operation may have to do two things: remove the
177 thread from the mutex's queue of waiting threads; and undo the
178 effects, if any, of priority inheritance. The implementation requires
179 extra fields in the thread data structure so that the kill routine
180 knows about the thread's current state, and extra code in the mutex
181 routines to fill in and clear these extra fields correctly.</P
183 >Most embedded applications do not require the ability to kill off a
184 thread asynchronously, and hence the kill routine will not get linked
185 into the final application image. Without compile-time configurability
186 this would still mean that the mutex code and similar parts of the
187 system contain code and data that serve no useful purpose in this
188 application. The <SPAN
191 > approach allows the user to select that the
192 thread kill functionality is not required, and all the components can
193 adapt to this at compile-time. For example the code in the mutex lock
194 routine contains statements to support the killing of threads, but
195 these statements will only get compiled in if that functionality is
196 required. The overall result is that the final application image
197 contains only the code and data that is really needed for the
198 application to work, and nothing else.</P
200 >Of course there are complications. To return to the button example,
201 the application code might only use text buttons directly, but it
202 might also use some higher-level widget such as a file selector and
203 this file selector might require buttons with pictures. Therefore the
204 button code must still be compiled to support pictures as well as
205 text. The configuration tools must be aware of the dependencies
206 between components and ensure that the internal constraints are met,
207 as well as the external requirements of the application code. An area
208 of particular concern is conflicting requirements: a button component
209 might be written in such a way that it can only support either text
210 buttons or picture buttons, but not both in one application; this
211 would represent a weakness in the component itself rather than in the
212 component framework as a whole.</P
214 >Compile-time configurability is not intended to replace the other
215 approaches but rather to complement them. There will be times when
216 run-time selection of behavior is desirable: for example an
217 application may need to be able to change the baud rate of a serial
218 line, and the system must then provide a way of doing this at
219 run-time. There will also be times when link-time selection is
220 desirable: for example a C library might provide two different random
228 >; these do not affect other code so there
229 is no good reason for the C library component not to provide both of
230 these, and allow the application code to use none, one, or both of
231 them as appropriate; any unused functions will just get eliminated at
232 link-time. Compile-time selection of behavior is another option, and
233 it can be the most powerful one of the three and the best suited to
234 embedded systems development.</P
241 SUMMARY="Footer navigation table"
252 HREF="overview.configurability.html"
261 HREF="cdl-guide.html"
270 HREF="overview.degress.html"
280 >Why Configurability?</TD
294 >Degrees of Configurability</TD
projects / karo-tx-redboot.git / blob