concepts.sgml

ecos实时嵌入式操作系统

kill routine to be able to function correctly. For example if a thread
is blocked while waiting on a mutex and is killed off by another
thread then the kill operation may have to do two things: remove the
thread from the mutex's queue of waiting threads; and undo the
effects, if any, of priority inheritance. The implementation requires
extra fields in the thread data structure so that the kill routine
knows about the thread's current state, and extra code in the mutex
routines to fill in and clear these extra fields correctly.
</para>
<para>
Most embedded applications do not require the ability to kill off a
thread asynchronously, and hence the kill routine will not get linked
into the final application image. Without compile-time configurability
this would still mean that the mutex code and similar parts of the
system contain code and data that serve no useful purpose in this
application. The &eCos; approach allows the user to select that the
thread kill functionality is not required, and all the components can
adapt to this at compile-time. For example the code in the mutex lock
routine contains statements to support the killing of threads, but
these statements will only get compiled in if that functionality is
required. The overall result is that the final application image
contains only the code and data that is really needed for the
application to work, and nothing else.
</para>
<para>
Of course there are complications. To return to the button example,
the application code might only use text buttons directly, but it
might also use some higher-level widget such as a file selector and
this file selector might require buttons with pictures. Therefore the
button code must still be compiled to support pictures as well as
text. The configuration tools must be aware of the dependencies
between components and ensure that the internal constraints are met,
as well as the external requirements of the application code. An area
of particular concern is conflicting requirements: a button component
might be written in such a way that it can only support either text
buttons or picture buttons, but not both in one application; this
would represent a weakness in the component itself rather than in the
component framework as a whole.
</para>
<para>
Compile-time configurability is not intended to replace the other
approaches but rather to complement them. There will be times when
run-time selection of behavior is desirable: for example an
application may need to be able to change the baud rate of a serial
line, and the system must then provide a way of doing this at
run-time. There will also be times when link-time selection is
desirable: for example a C library might provide two different random
number routines <function>rand</function> and
<function>lrand48</function>; these do not affect other code so there
is no good reason for the C library component not to provide both of
these, and allow the application code to use none, one, or both of
them as appropriate; any unused functions will just get eliminated at
link-time. Compile-time selection of behavior is another option, and
it can be the most powerful one of the three and the best suited to
embedded systems development.
</para>

</sect1>

<!-- }}} -->
<!-- {{{ Degrees                -->

<sect1 id="overview.degress">
<title>Degrees of Configurability</title>

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

<orderedlist>

<listitem>
<para>
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.
</para>
</listitem>

<listitem>
<para>
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.
</para>
<para>
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.
</para>
<para>
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.
</para>
</listitem>

<listitem>
<para>
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.
</para>
</listitem>

<listitem>
<para>
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.
</para>
</listitem>

<listitem>
<para>
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
<function>malloc</function> 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.
</para>
</listitem>

<listitem>
<para>
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.
</para>
</listitem>

<listitem>
<para>
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.
</para>
</listitem>

</orderedlist>

<para>
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.
</para>
<para>
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.
</para>
</sect1>

<!-- }}} -->
<!-- {{{ Warning                -->

<sect1 id="overview.warning">
<title>Warnings</title>
<para>
Large parts of &eCos; were developed concurrently with the development
of the configuration technology, or in some cases before design work
on that technology was complete. As a consequence the various &eCos;
packages often make only limited use of the available functionality.
This situation is expected to change over time. It does mean that many
of the descriptions in this guide will not correspond exactly to how
the &eCos; packages work right now, but rather to how they could work.
Some of the more extreme discrepancies such as the location of on-line
documentation in the component repository will be mentioned in the
appropriate places in the guide.
</para>
<para>
A consequence of this is that developers of new components can look at
existing &CDL; scripts for examples, and discover discrepancies
between what is recommended in this guide and what actually happens at
present. In such cases this guide should be treated as authoritative.
</para>
<para>
It is also worth noting that the current component framework is not
finished. Various parts of this guide will refer to possible changes
and enhancements in future versions. Examining the source code of the
configuration tools may reveal hints about other likely developments,
and there are many more possible enhancements which only exist at a
conceptual level right now.
</para>

</sect1>

<!-- }}} -->

</chapter>