HOWTOs

There are three categories of HOWTOs:

• RTOS and RT application
• RT latency debugging
• RT tools and utilities

Technical Basics

Currently running tasks with low priority must be preempted to allow the real-time critical task to run. Preemption depends on the rules of the task’s scheduling policy. Another important aspect in a real-time system is the guaranteeing the exclusive use of certain resources for real-time tasks.

Technical details of PREEMPT_RT patch

The main aim of the PREEMPT_RT patch is to minimize the amount of kernel code that is non-preemptible ¹⁾. Therefore several substitution mechanisms and new mechanisms are implemented.

Publications

Several real-time related publications can help broaden your knowledge about real-time systems. Regarding PREEMPT_RT, a recent survey of available scientific works have been published (open access link).

Known Limitations

Some functionality is not available on RT because its implementation is not compatible with RT. Those limitations may apply to the to the kernel as a whole or may apply to specific architecture or platforms.

Stable RT Releases

If the PREEMPT_RT patch was ported to a Linux kernel version that is flagged as a stable release at kernel.org, then that port will continue to be forward ported with each new stable release for that kernel version. The stable kernels can be cloned from the stable git repository as well as downloaded as single patches or a tarball of a quilt series of patches.

The PREEMPT_RT stable releases are updated in two fashions.

• Merged with the upstream Linux stable kernel.

• Backports of commits from the current PREEMPT_RT development repository

Tagging policy of the PREEMPT_RT stable releases. Each PREEMPT_RT stable release is tagged with the version number of the upstream Linux stable kernel as well as its own “-rt” counter that is appended. The -rt counter will increment for the following:

• When forward ported to the latest upstream Linux stable version.

• When any merge with a upstream Linux stable causes a conflict.

• When a backport of the PREEMPT_RT development branch is done.

A backport will not be done with a forward port of a stable version. They will be done separately, and tagged separately.

The “-rebase” branch is how the series of patches are created. The “-rebase” is only done for forward ports to the latest upstream Linux stable versions, and for backports of the PREEMPT_RT development branch. It is not done for a conflict with a upstream Linux stable merge, unless that stable version is the latest one. As the name suggests, the “-rebase” branch will rebase, to allow each commit added by the PREEMPT_RT code to be applied in the order to the upstream Linux stable version it is based on. This is not the case with the normal “-rt” branch, which is never rebased.