|
|
Application-defined Scheduler
|
|
Description:
|
Application-defined scheduling (ADS for short) is an application program interface (API) that enables applications to use application-defined scheduling algorithms in a way compatible with the scheduling model defined in POSIX. Several application-defined schedulers, implemented as special user threads, can coexist in the system in a predictable way. The application defined scheduler in RTLinux is a key facility which will help in the adoption of the already available scheduling theory.
|
|
Keywords:
|
Real-Time, POSIX, scheduling
|
|
Version:
|
0.2-1
|
Status:
|
Stable
|
[more ...]
|
|
|
Two Level Segregate Fit Memory Allocator
|
|
Description:
|
This component provides dynamic memory allocation with real time characteristics (malloc and free). The allocator implemented in this component is a new algorithm specially designed with the aim of obtaining bounded response time. The new algorithm is called TLSF Two Level Segregated Fit (the first versions were called DYDMA). It is based on the use of a pure segregated strategy. See [Paul 95] for an exhaustive taxonomy and review of existing DSA algorithms. The code is provided as a library that can be compiled to be used in several environments: Linux kernel, RTLinux, and Linux applications.
|
|
Keywords:
|
Real-Time, Dynamic Memory, DIDMA, malloc, free
|
|
Version:
|
1.4
|
Status:
|
Stable
|
[more ...]
|
|
|
POSIX Execution-Time Clocks
|
|
Description:
|
When performing a schedulability test, scheduling analysis relies on a known worst-case execution time (WCET). Nevertheless, estimating WCET is a difficult task due to the different execution paths within a program and today's computer architectures. Without bound on execution time, a task could execute more than estimated, causing other tasks to loose its deadlines. This, on most hard real time application, may result in catastrophic consequences. This component tries to give a solution to this problem, implementing execution time timers within the task scheduler. This kind of timers may be used to detect execution time overruns in the application, and to limit their effects. As an example, if a timer is created using a CPU-Time clock of a particular thread, and a relative expiration time is given, it can be used to notify that a certain budget of execution time has elapsed, for that thread. If the timer is armed each time a thread is activated, and the relative expiration time is set to the thread's estimated worst-case execution time (plus some small amount to take into account the limited resolution and precision of the CPU-Time clock), then the timer will only expire if the thread suffers an execution time overrun.
|
|
Keywords:
|
Real-Time, POSIX, timers
|
|
Version:
|
0.1-1
|
Status:
|
Testing
|
[more ...]
|
|
|
POSIX Barriers
|
|
Description:
|
Barriers, are defined in the advanced real-time POSIX (IEEE Std 1003.1-2001), as part of the advanced real-time threads extensions. A barrier is a simple and efficient synchronisation utility. Threads using a barrier must wait at a specific point until all have finished before any of them can continue.
|
|
Keywords:
|
Real-Time, POSIX, barriers, synchronisation
|
|
Version:
|
0.1-1
|
Status:
|
Testing
|
[more ...]
|
|
|
POSIX Message Queues
|
|
Description:
|
UNIX systems offers several possibilities for interprocess communication: signals, pipes and FIFO queues, shared memory, sockets, etc. In RTLinux, the most flexible one is shared memory, but the programmer has to use alternative synchronisation mechanism to build a safe communication mechanism between process or threads. On the other hand, signals and pipes lack certain flexibility to establish communication channels between process. In order to cover some of these weaknesses, POSIX standard proposes a message passing facility that offers: 1) Protected and synchronised access to the message queue. Access to data stored in the message queue is properly protected against concurrent operations. 2) Prioritised messages. Processes can build several flows over the same queue, and it is ensured that the receiver will pick up the oldest message from the most urgent flow. 3) Asynchronous and temporised operation. Processes have not to wait for operation to be finish, i.e., they can send a message without having to wait for someone to read that message. They also can wait an specified amount of time or nothing at all, if the message queue is full or empty. 4) Asynchronous notification of message arrivals. A receiver process can configure the message queue to be notified on message arrivals. So such a process can be working on something else until the expected message arrives.
|
|
Keywords:
|
Real-Time, POSIX, communication, IPC
|
|
Version:
|
0.2-1
|
Status:
|
Testing
|
[more ...]
|
|
|
POSIX Signals
|
|
Description:
|
Signals are an integral part of multitasking in the UNIX/POSIX environment. Signals are used for many purposes, including exception handling (bad pointer ac- cesses, divide by zero, etc.), process notification of asynchronous event occurrence (timer expiration, I/O completion, etc.), emulation of multitasking and interprocess communication. This component (package) provides POSIX signal implementation. It does not support real-time POSIX signals, but classic UNIX(r) signals. POSIX standard does not provide a clear description of how signals should be handled in a multi-threading environment. We tried our best to provide an implementation as close as possible to the standard.
|
|
Keywords:
|
Real-Time, POSIX, Signals
|
|
Version:
|
0.2-1
|
Status:
|
Stable
|
[more ...]
|
|
|
POSIX Timers
|
|
Description:
|
POSIX timers provides mechanisms to notify a thread when the time (measured by a particular clock) has reached a specified value, or when a specified amount of time has passed. Although RTLinux has good and accurate timing facilities, it does not provide general timer functionality. RTLinux defines only one timer for each thread, which is used to implement the periodic behaviour of the thread. This component implements the POSIX real-time extensions.
|
|
Keywords:
|
Real-Time, POSIX, timers
|
|
Version:
|
0.2-1
|
Status:
|
Stable
|
[more ...]
|
|
|
POSIX Trace
|
|
Description:
|
As realtime applications become bigger and more complex, the availability of event tracing mechanisms becomes more important in order to perform debugging and run- time monitoring. Recently, IEEE has incorporated tracing to the facilities defined by the POSIX standard. The result is called the POSIX Trace standard. Tracing can be defined as the combination of two activities: the generation of tracing information by a running process, and the collection of this information in order to be analysed. The tracing facility plays an important role in the OCERA architecture. Besides its primary use as a debugging and tuning tool, the tracing component jointly with the application-defined scheduler component constitute the key tools for building fault-tolerance mechanisms.
|
|
Keywords:
|
Real-Time, POSIX, debug, trace, time analysis
|
|
Version:
|
1.0-1
|
Status:
|
Stable
|
[more ...]
|
|
|
Constant Bandwith Server (CBS) Scheduler in RTLinux
|
|
Description:
|
CBS scheduling policy efficiently handle soft real-time requests with a variable or unknown execution behaviour under EDF scheduling policy. This component modifies the RTLinux source code to support this scheduling policy. The Constant Bandwidth Server (CBS) [Abeni98] was developed to efficiently handle soft real-time requests with a variable or unknown execution behaviour under EDF scheduling policy. To avoid unpredictable delays on hard real-time tasks, soft tasks are solated through a bandwidth reservation mechanism, according to wich each soft task s assigned a fraction of the CPU and it is scheduled in such a way that it will never demand more than its reserved bandwidth, independently of its actual requests. This is achieved by assigning each soft task a deadline, computed as a function of the reserved bandwidth and its actual requests. If a task requires to execute more than its expected computation time, its deadline is postponed so that its reserved bandwidth is not exceeded. As a consequence, overruns ocurring on a served task will only delay that task, without compromising the bandwidth assigned to other tasks. By isolating the effects of task overloads, hard tasks can be guaranteed using classical schedulability analysis.
|
|
Keywords:
|
Scheduling, Real-Time, Aperiodic, QoS
|
|
Version:
|
0.1-1
|
Status:
|
Stable
|
[more ...]
|
|
|
C++ RTLinux support
|
|
Description:
|
This component provides support for the C++ language (that is, objects, exceptions, etc.), however this component does not implement support for the C++ libraries which will have to be replaced by the user by calls to the RTLinux API.
|
|
Keywords:
|
RTLinux Porting, C++
|
|
Version:
|
0.1
|
Status:
|
Stable
|
[more ...]
|
|
|
GNAT (Ada 95 compiler) porting to RTLinux
|
|
Description:
|
The Real-Time Linux OS (RTLinux) is an attractive platform for realtime programming, since real-time tasks can be guaranteed bounded response times, while a number of applications, IDEs, GUIs, etc. are also available for the same platform. In RTLinux, real-time tasks are implemented as kernel modules, implemented in "C". Special care must be taken when writing these modules: a bug in a single task can make the whole system to hang or crash, since these modules are executed in the kernel memory space. This is clearly an area where Ada can be of great help: Ada is strong typing, consistency checking, robust syntax and readability, and the availability of high quality compilers, encourage the writing of correct software and allow to catch bugs early in the implementation. RTLGnat is a modification of GNAT Ada compiler to allow to write RTLinux modules in Ada.
|
|
Keywords:
|
Real-Time, ADA95, GNAT
|
|
Version:
|
1.0
|
Status:
|
Stable
|
[more ...]
|
|
|
RTLinux ide/filesystem driver
|
|
Description:
|
RTLinux does not support direct access to any kind of permanent massive storage systems, and in particular IDE hard disks. When a RTLinux thread has to storage data on the hard disk, it has to use the Linux services. The usual way of doing the transfer is by means of RTFifos: a rtl-task sends the data to Linux through an RTfifo, and then, a Linux process writes this data on the hard disk. The exitsting method to access hard disks is slow, unpredictable and inneficient, since it is executed by the Linux (background). Moreover, in some applications, like continuous media applications, it is required a certain degree of predictability. Therefore, for multimedia applications is more convenient that rtl-tasks have access to the hard drive, so that disk access can be done with real-time guarantees. To achieve this goal it is necessary to: 1) port the IDE driver to RTLinux, 2) implement a real-time filesystem. This component provides the porting of the Linux IDE driver to RTLinux, and a rtlfs filesystem.
|
|
Keywords:
|
Real-Time, IDE driver, file system
|
|
Version:
|
0.3-1
|
Status:
|
Testing
|
[more ...]
|
|
|
RTLinux Java
|
|
Description:
|
This component provides a JAVA virtual machine running in RTLinux/GPL. Please, note that this component is not a full functional virtual machine, but a prove of concept. We just wanted to know whether it was possible or not. And the conclusion is that it can be done.
|
|
Keywords:
|
RTLinux Porting
|
|
Version:
|
0.1
|
Status:
|
Alpha
|
[more ...]
|
|
|
RTLinux Terminal
|
|
Description:
|
Currently, RTLinux human user interface capability is limited to directly print strings via functions: conprn() or rtl_printf(). Direct user input from keyboard is not possible. Complex interaction with the human user (data representation, and user input) has to be done by a non real-time Linux application communicated with the RTLinux application via shared memory or RT-FIFO's. These communication mechanisms are non-portable specific RTLinux facilities. Also, the access to the video and keyboard can not be done in real-time since it is delayed until Linux became active. RT-Terminal is a new component that allows to RTLinux applications display data directly on the console screen and read the pressed keys directly from the keyboard. RT-Terminal will provide direct access to the console to RTLinux applications and at the same time it will keep compatibility with the existing Linux console drivers. RT-Terminal will also be used by the Stand-Alone RTLinux component, since standalone can not use the linux kernel to print on the screen.
|
|
Keywords:
|
Terminal, User interface
|
|
Version:
|
0.1-1
|
Status:
|
Testing
|
[more ...]
|
|
|
RTLinux UDP/IP
|
|
Description:
|
This component is an implementation of the UDP/IP stack from scratch (not derived from BSD code as many other TCP/UDP/IP implementations). The main design criteria is efficiency, while features and compatibility are secondary. The stack will be prepared (interfaced) to work with the network device drivers developed in the project EtherBoot, which has a large base of supported drivers; and also be connected with the Linux networking stack (via a virtual network driver), providing a high level communication mechanism between RTLinux and Linux on the same machine.
|
|
Keywords:
|
Terminal, User interface
|
|
Version:
|
0.1-1
|
Status:
|
Testing
|
[more ...]
|
|
|
Stand-Alone RTLinux
|
|
Description:
|
Stand-Alone RTLinux will be a Linux independent implementation of RTLinux. Stand-Alone RTLinux will be a bootable executive with the following main features: a) Low memory overhead. The core systems contains only following modules: the code of RTLinux, the minimum code needed to boot the system and basic virtual memory management. b) Scalability. Users will be able to customize RTLinux funcionalities to reduce kernel memory usage. c) Porting will be possible to systems without hardware for virtual memory support. Therefore, Stand-Alone RTLinux could be ported to a wider range of architectures. d) Less TLB and memory cache misses (or none at all, if paging is not activated) since only real-time applications are being executed. e) We are not longer limited by the Linux memory manager. Standard RTLinux memory management relays completely on the Linux so it is not possible to implement custom virtual memory management algorithms. Stand-Alone RTLinux has full control of the MMU. Current implementation provides three different memory schemes: 1.- Non protected memory. RTLinux executive and application can read and write at any memory location. 2.- Simple memory protection. The application can not write into the RTLinux executive memory space, and null pointers are catched. 3.- Context memory protection: Several applications (each application can run one or more threads) are executed in a protected memory space. Each aplication can read and write its own data but only read system and other applications code and data.
|
|
Keywords:
|
RTLinux Porting
|
|
Version:
|
2.2-pre2
|
Status:
|
Stable
|
[more ...]
|
|
|
XtratuM
|
|
Description:
|
XtratuM is an open source nanokernel (or better a picokernel) that goes beyond the classical ideas of nanokernels (www.xtratum.org). Basically, XtratuM is just two simple device drivers: interrupt and timer. It can be used to replace the current HAL of RTLinux, avoiding the RTLinux patents, as far as we reckon.
|
|
Keywords:
|
Nanokernel, multiple-domain multiplexed
|
|
Version:
|
0.1
|
Status:
|
Stable
|
[more ...]
|
|
Status codes:
Analysis
>>
Design
>>
Alpha
>>
Beta
>>
Testing
>>
Stable
|
