|
OCERA Components
An OCERA component is defined as follows:
“A piece of software that brings some new functionality or
feature at different levels in some of the fields: Scheduling, Quality
of Service, Fault-Tolerance and Communications”.
This is a fairly general definition that will be extended and
detailed next. As a piece of software we mean:
 a
modification of the Linux kernel or RTLinux executive, which will
be released as a
patch file against a specific kernel version or integrated into
the final OCERA kernel;
a
module which can be loaded (with the insmod/modprobe commands) and
provides
new functionalities and may use some of the already installed services;
a library, dynamic or static, which can be linked with the user
application;
or
a standalone thread or process (for example a debugging program).
Component classification
OCERA components can be classified according to two criteria:
- Protection: According to the “protection”
criteria, we can identify components that run in user space
and components that run in kenel space. User space components
are Linux applications
running in their own address spaces at the lowest privilege level.
Because of the protection
mechanism enforced by the Linux kernel, these components are not
able to crash
the system, even if they misbehave and try to access random memory
locations.
Components running in kernel space are: the (patched) Linux kernel
(including its own
device drivers), the RTLinux executive, and the hard real-time
tasks (also referred as
RTLinux tasks or RTLinux applications).
- Level: According to the “level”
criteria, kernel space components can be located in the RTLinux
layer (as modifications or additions to the RTLinux executive)
or in the Linux layer (as
modifications to the Linux kernel, which are independent from
RTLinux).
Architecture Level
OCERA architecture can be split in several level:
RTLinux level
| |
Low-level RTLinux: This kind of components
are highly related with the current RTLinux capabilities or
internal algorithms, thus it requires to modify the current
RTLinux source code in order to provide the new functionality
or to improve an available one. This kind of component will
be distributed in a patch-form and hopefully incorporated
in the main stream of the implied kernel source.
High-level
RTLinux: It only needs the current API of the RTLinux
kernel or an extended API offered by other kernel component
in order to implement its new functionality. It does not require
to modify the existing kernel source code or any low-level
kernel component.
RTLinux
Applications: This kind of component uses the kernel
API to provide a new service. It does not require to modify
the existing kernel source code or any kernel component. The
main characteristic of these components are that they are
implemented as an application-level processes/threads, offering
some kind of service to other processes/threads (as a kind
of a classical UNIX daemon).
|
Linux level
| |
Low-level Linux : Like the low-level RTLinux
executive components, these components
modify the current kernel and has to be distributed as patch
files.
High-level
Linux : Components located inside the Linux kernel
that use but do
not modify the Linux kernel code. Device drivers are components
of this category.
The third level (Linux applications) coincides with user space
applications.
Most of the components will fit in one of these categories,
but others will require the
modification of several layers. For example, the CBS component
at the RTLinux executive
will also require small modifications of the Linux kernel.
|
In the component description you will find precise information
about its protection level (user space / kernel space) ant its location
(RTLinux layer / Linux layer).
|
