|WP2 - Architecture Specification: Deliverable D2.1 - Architecture and Components Integration|
|Prev||Chapter 5. Kernel Components||Next|
In this section, a description of the kernel components that will be developed and where they are situated in the kernel components architecture is presented.
The kernel components presented bellow will be developed mainly for the RTLinux kernel, because some of these services are already available in the Linux kernel.
As it was described above, these components require the modification of the currently available kernels in order to extends their current API with new real-time functionalities.
This component will provide a mechanism by which a process or thread may be notified of, or affected by, an event occurring in the system. Examples of such events include hardware exceptions and specific actions by processes.
The Real-time signals is a deterministic signal extension that allows asynchronous signal notifications to an application to be queued without impacting compatibility with the existing signal functions.
A mechanism that can notify a thread when the time as measured by a particular clock has reached or passed a specified value, or when a specified amount of time has passed.
This component needs POSIX signals to notify the timer owner of its expiration and it has to modify the kernel scheduler to manage timer events.
Barriers, are defined in the advanced realtime POSIX (IEEE Std 1003.1-2001). A barrier is a simple and efficient synchronisation utility. A barrier can be implemented inefficiently by mean of a mutex and condition variables, but the proposed implementation will relay on special processor instructions to achieve low overhead.
Recently, IEEE Std 1003.1-2001, POSIX provides a new debugging facility: POSIX tracing. POSIX trace implementation jointly with a tool to display and analyse the logged data will be a very useful tool for realtime developers.
It is an RTOS API proposal to allow the user application to define the scheduling algorithm for its system.
This new API will be provide the capability of implementing new scheduling policies without modifying the kernel scheduler. Using this new functionality, an application thread can decide how other threads of the same process should be scheduled. It is also possible that multiple application schedulers coexist in the same real-time application.
These components provide basic mechanisms for process/thread synchronisation, timed execution and system monitoring. All of them are desirable to build real-time applications and to develop more powerfull real-time components.
These kind of components provide a new API that extends the real-time API of Linux and RTLinux kernels. As they does not require to modify the kernel source code, it can be provided as separated loadable modules, application libraries or incorporated into the kernel mainstream, if preferred.
The IEEE Std 1003.1-2001 specification defines a prioritised message passing facility for the realtime and embedded environments. Among others features, this message system will provides: prioritization of messages, asynchronous notification, and fixed size messages.
This powerfull message passing facility is not available in any of the two kernels, Linux and RTLinux. This component should provide such facility using only the API provided by the kernel plus the API provided by the low-level kernel components, more precisely, using POSIX signals and timers.
The RTLinux kernel lacks of a dynamic memory manager, and therefore, hard real-time threads and drivers that should be allocated in the RTLinux kernel cannot use any kind of dynamic memory allocation. This is a very strong restriction in same cases.
This component should provide a highly customisable and fully deterministic manager that allows hard real-time threads and low-level drivers to allocate memory dynamically.
RTLinux applications can be programmed in C and C++ . Another important programming language for realtime systems is ADA. The ADA run time support has to be ported to RTLinux in order to run ADA programs. This component will provide such support in the RTLinux kernel.
These components and the low-level kernel components will be provide the required functionalities to develop more complex components, such QoS, communication and fault-tolerance components and to build reliable real-time embedded applications.
This kind of components is not the typical kernel component, and its existence is reduced to a small set of threads that provide scheduling and monitoring support to the other threads. This kind of components will be mainly developed as a QoS and fault-tolerance components.
These components, implemented as application-level threads, will provide some scheduling facilities to other threads without modifying the system scheduler.
One of the schedulers that will be implemented is the Constant Bandwidth Server. This scheduler should provide a guarantee amount of CPU time to other real-time threads.
Next figure shows the kernel components distributions inside the OCERA software architecture.