+++ /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
->Degrees of 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="Approaches to Configurability"
-HREF="overview.approaches.html"><LINK
-REL="NEXT"
-TITLE="Warnings"
-HREF="overview.warning.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.approaches.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.warning.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="SECT1"
-><H1
-CLASS="SECT1"
-><A
-NAME="OVERVIEW.DEGRESS">Degrees of Configurability</H1
-><P
->Components can support configurability in varying degrees. It is not
-necessary to have any configuration options at all, and the only user
-choice is whether or not to load a particular package. Alternatively
-it is possible to implement highly-configurable code. As an example
-consider a typical facility that is provided by many real-time
-kernels, mutex locks. The possible configuration options include:</P
-><P
-></P
-><OL
-TYPE="1"
-><LI
-><P
->If no part of the application and no other component requires mutexes
-then there is no point in having the mutex code compiled into a
-library at all. This saves having to compile the code. In addition
-there will never be any need for the user to configure the detailed
-behavior of mutexes. Therefore the presence of mutexes is a
-configuration option in itself.</P
-></LI
-><LI
-><P
->Even if the application does make use of mutexes directly or
-indirectly, this does not mean that all mutex functions have to be
-included. The minimum functionality consists of lock and unlock
-functions. However there are variants of the locking primitive such as
-try-lock and try-with-timeout which may or may not be needed.</P
-><P
->Generally it will be harmless to compile the try-lock function even if
-it is not actually required, because the function will get eliminated
-at link-time. Some users might take the view that the try-lock
-function should never get compiled in unless it is actually needed, to
-reduce compile-time and disk usage. Other users might argue that there
-are very few valid uses for a try-lock function and it should not be
-compiled by default to discourage incorrect uses. The presence of a
-try-lock function is a possible configuration option, although it may
-be sensible to default it to true.</P
-><P
->The try-with-timeout variant is more complicated because it adds a
-dependency: the mutex code will now rely on some other component to
-provide a timer facility. To make things worse the presence of this
-timer might impact other components, for example it may now be
-necessary to guard against timer interrupts, and thus have an
-insidious effect on code size. The presence of a lock-with-timeout
-function is clearly a sensible configuration option, but the default
-value is less obvious. If the option is enabled by default then the
-final application image may end up with code that is not actually
-essential. If the option is disabled by default then users will have
-to enable the option somehow in order to use the function, implying
-more effort on the part of the user. One possible approach is to
-calculate the default value based on whether or not a timer component
-is present anyway.</P
-></LI
-><LI
-><P
->The application may or may not require the ability to create and
-destroy mutexes dynamically. For most embedded systems it is both less
-error-prone and more efficient to create objects like mutexes
-statically. Dynamic creation of mutexes can be implemented using a
-pre-allocated pool of mutex objects, involving some extra code to
-manipulate the pool and an additional configuration option to define
-the size of the pool. Alternatively it can be implemented using a
-general-purpose memory allocator, involving quite a lot of extra code
-and configuration options. However this general-purpose memory
-allocator may be present anyway to support the application itself or
-some other component. The ability to create and destroy mutexes
-dynamically is a configuration option, and there may not be a sensible
-default that is appropriate for all applications.</P
-></LI
-><LI
-><P
->An important issue for mutex locks is the handling of priority
-inversion, where a high priority thread is prevented from running
-because it needs a lock owned by a lower priority thread. This is only
-an issue if there is a scheduler with multiple priorities: some
-systems may need multi-threading and hence synchronization primitives,
-but a single priority level may suffice. If priority inversion is a
-theoretical possibility then the application developer may still want
-to ignore it because the application has been designed such that the
-problem cannot arise in practice. Alternatively the developer may want
-some sort of exception raised if priority inversion does occur,
-because it should not happen but there may still be bugs in the code.
-If priority inversion can occur legally then there are three main ways
-of handling it: priority ceilings, priority inheritance, and ignoring
-the problem. Priority ceilings require little code but extra effort on
-the part of the application developer. Priority inheritance requires
-more code but is automatic. Ignoring priority inversion may or may not
-be acceptable, depending on the application and exactly when priority
-inversion can occur. Some of these choices involve additional
-configuration options, for example there are different ways of raising
-an exception, and priority inheritance may or may not be applied
-recursively.</P
-></LI
-><LI
-><P
->As a further complication some mutexes may be hidden inside a
-component rather than being an explicit part of the application. For
-example, if the C library is configured to provide a
-<TT
-CLASS="FUNCTION"
->malloc</TT
-> call then there may be an associated mutex
-to make the function automatically thread-safe, with no need for
-external locking. In such cases the memory allocation component of the
-C library can impose a constraint on the kernel, requiring that
-mutexes be provided. If the user attempts to disable mutexes anyway
-then the configuration tools will report a conflict.</P
-></LI
-><LI
-><P
->The mutex code should contain some general debugging code such as
-assertions and tracing. Usually such debug support will be enabled or
-disabled at a coarse level such as the entire system or everything
-inside the kernel, but sometimes it will be desirable to enable the
-support more selectively. One reason would be memory requirements: the
-target may not have enough memory to hold the system if all debugging
-is enabled. Another reason is if most of the system is working but
-there are a few problems still to resolved; enabling debugging in the
-entire system might change the system's timing behavior too much, but
-enabling some debug options selectively can still be useful. There
-should be configuration options to allow specific types of debugging
-to be enabled at a fine-grain, but with default settings inherited
-from an enclosing component or from global settings.</P
-></LI
-><LI
-><P
->The mutex code may contain specialized code to interact
-with a debugging tool running on the host. It should be
-possible to enable or disable this debugging code, and there may
-be additional configuration options controlling the detailed
-behavior.</P
-></LI
-></OL
-><P
->Altogether there may be something like ten to twenty configuration
-options that are specific to the mutex code. There may be a similar
-number of additional options related to assertions and other debug
-facilities. All of the options should have sensible default values,
-possibly fixed, possibly calculated depending on what is happening
-elsewhere in the configuration. For example the default setting for
-an assertion option should generally inherit from a kernel-wide
-assertion control option, which in turn inherits from a global option.
-This allows users to enable or disable assertions globally or at
-a more fine-grained level, as desired.</P
-><P
->Different components may be configurable to different degrees, ranging
-from no options at all to the fine-grained configurability of the
-above mutex example (or possibly even further). It is up to component
-writers to decide what options should be provided and how best to
-serve the needs of application developers who want to use that
-component.</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.approaches.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.warning.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
->Approaches to Configurability</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="overview.html"
-ACCESSKEY="U"
->Up</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->Warnings</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file