Download Trusted embedded System Operating System (TeSOS)

codes including EINVAL and EDEADLK. Several problems may occur if applications implement
error handling routines:
•
Error handling during mutex lock or any kernel function requires CPU resources not to be
underestimated.
•
It is not unusual that functions return error codes which are not handled by the calling
function, since the programmers often expect that the called function works as expected.
•
Each caller of a function has to check for possible errors returned by the called function.
This also costs CPU cycles and increases the code size of the application.
•
It can happen that an error occurs where there is no way to handle it, e.g., EINVAL. The
only thing an application can do in this case is to abort the application.
In contrast to common error handling, the eCos now does the following: Functions, such as
cyg_mutex_lock() will not return an error code.
Instead, eCos functions contain a couple of
assertions which can be enabled or disabled. Normally, these assertions are left enabled during the
development phase and a lot of kernel functions will perform parameter checks and other system
consistency checks. If a problem is detected, an assertion will be reported and the application
will be terminated, allowing developers to check for possible errors. If the application is released,
these assertions are disabled during compile-time. In general, this is similar to a debug-ag of
some common desktop applications where additional debug-operations are included with some
compiler-ag.
An error condition of several APIs functions is lack of memory. Some kernel functions allocate
some memory dynamically for some thread stack or other per-thread data.
If now the used
hardware is not equipped with enough memory or the application contains a memory leak, the
function call would fail. The eCos kernel now avoids such problems by never performing dynamic
memory allocations. Instead, it is the responsibility of the application code to provide all memory
required for kernel data structures. A lot of applications handle this with dening data structures
statically and not dynamically. Problems, such as memory fragmentation or leaks, cannot occur
if all data is allocated statically.
Since eCos partly supports SMP, some adaptations are required, e.g., the scheduling has to
be dierent since now threads have to be divided into several CPUs leading to additional race
conditions. During the initialization phase, the system behaves as if only one CPU is present.
In principle, the used scheduler lock is converted into a nestable spin-lock, achieved by adding
a spin-lock and a CPU id to the original counter. If a thread causes a scheduler lock and the
CPU id is equal to the current CPU then it can increment the internal counter and continue.
If the id does not match, the CPU must spin on the spin-lock, after which it may increment
the corresponding counter and store its own identity number in the CPU id. Releasing the lock
again is possible through decrementing the counter. If the counter reaches zero, the spin-lock is
cleared. In the current version of eCos, SMP is only supported by the above mentioned MultiLevel Queue scheduler. Therefore, the scheduler now divides its threads to run the threads with
the highest priority on all available CPUs.
7.2.2 Protection
eCos does not support any additional protection models, nor restricts the direct access to hardware, or secure mechanisms to grand or deny access to the memory (except by the already
described resource-management). There are no protection rings or any support for trusted anchors as introduced in Section 5.1.4.
7.2.3 Power Management
Although the eCos operating system provides a package responsible for power management,
functionality to save energy is very limited.
The package does not support any reduction of
CPU speed or any other power-saving method provided by the hardware. In comparison, eCos
116