posix.tex

rtai-3.1-test3的源代码(Real-Time Application Interface )

\chapter{Posix - RTAI/fusion}

% ----------------------------------------------------------------------------

\section{The New POSIX Approach}

In older RTAI versions POSIX compatiblity has been achieved by writing 
several modules which implemented the standard POSIX APIs in RTAI 
modules. This approach has turned out to be problematic and difficult
to maintain, so a new scheme has been invented. 

Instead of rewriting a complete POSIX layer usable in a real-time
context, a way has been found to move the existing user-space Linux
support seamlessly into the RTAI realm. This basically allows to call
regular Linux syscalls synchronously from RTAI tasks running in
user-space, while keeping the scheduling priority of the caller
unaffected by the domain migration.

This approach offers a number of advantages:

\begin{itemize}

\item Conflicts (source-wise and execution-wise) between the RTAI-specific
and native POSIX interfaces (Linuxthreads/NPTL) cannot occur, since
there is no need for any RTAI-specific interface in the first place.

\item Since user-space thread interfaces use kernel syscalls to perform
thread synchronization and other management, interface upgrades should
have very little impact on the RTAI POSIX support. Conversely, RTAI
should benefit from POSIX interface upgrades at low or even no cost.

\item All user-space services are now automatically RTAI-enabled,
i.e. real-time compatible, provided they are thread-safe in the first
place. Obviously, this does not mean that Linux services miraculously
become time-bounded with this extension, but at least, they are now
callable from any RTAI task context. It is still up to the user to
evaluate the suitability of calling such code in a real-time context
though.

\end{itemize}

% ----------------------------------------------------------------------------

\subsection{How it works}

LXRT is able to migrate user-space tasks back and forth between the
Linux and RTAI domains, depending on the requested operating mode.

Hard real-time mode is obtained by stealing the current task from the
Linux's scheduler runqueue and readying it for the LXRT
scheduler. Since the latter also reinstates the MMU-context of any
incoming task, the net result is that we have memory protected tasks
solely scheduled by RTAI. After this transition, the migrated/stolen
task left in \texttt{TASK\_UNINTERRUPTIBLE} state disappears from Linux's radar,
just like any suspended task, assuming that some code somewhere will
care for resuming it when it's due. At this point, the RTAI scheduler
can pick this task and reinstate its MMU-context when it switches it
back in.

Migration from Linux to RTAI needs a helper task controlled by Linux
(namely, \texttt{kthread\_b}) which is resumed by RTAI, and whose job is to move
any given real-time task to RTAI's ready task queue, then trigger a
fast real-time rescheduling to make such task resume into the RTAI
domain immediately. The action of waking up this helper task after the
migrating task has been suspended (state == \texttt{TASK\_UNINTERRUPTIBLE})
conveniently ensures that the Linux runqueue correctly reflects the
new situation.

The following pseudo-code example shows how it works: 

\begin{code}
T1 runs in soft real-time mode...
        T1 calls make_hard_realtime()
                T1 Linux state is set TASK_UNINTERRUPTIBLE
                kthread_b() kernel thread is woken up
kthread_b() runs... (T1 is now out of Linux's runqueue)
        kthread_b() fast schedules back T1
T1 immediately resumes in hard real-time mode...
\end{code}

Migration from RTAI to Linux is somewhat simpler, only requiring a
RTAI service request to be scheduled so that \texttt{wake\_up\_process()} is
called on the migrating task as soon as the Linux kernel gets back in
control.

% ----------------------------------------------------------------------------

\subsection{Side-effect of a soft-mode transition in LXRT}

Soft-mode transition is caused by an explicit call to
\texttt{make\_soft\_realtime()}, or implicitely done by LXRT when a Linux syscall
is caught from a hard real-time task. LXRT also makes sure that such
task goes back to hard real-time as soon as the Linux syscall has
completed.

The first effect of the soft-mode transition is to lower the calling
task's priority down to the Linux placeholder task
(i.e. \texttt{rt\_linux\_task}), representing the idle -- non real-time fallback
context. This is an accepted side-effect that such lowering also
affects the real-time priority handling, de facto excluding the soften
task from the real-time realm.

% ----------------------------------------------------------------------------

\section{Issues and solutions}

The following issues are raised when it comes to integrate the Linux
General Purpose Operating System (GPOS) kernel within the execution 
domain of a RTOS like RTAI:

\begin{itemize}

\item Linux internal design promotes fairness and throughput, at the
expense of determinism. The net effect is that many code paths in the
vanilla 2.4 Linux kernel are not preemptible for serving interrupts
and/or rescheduling tasks.

\end{itemize}

By increasing the overall preemptibility of the Linux
kernel, Montavista's "kpreempt" extension partly solves this
issue, by limiting the non-preemptible sections to those
protected by a spinlock, and calling the rescheduling
procedure on exit of such sections if needed. Coupling Andrew
Morton's low latency patch further reduces the length of such
non-preemptible sections.

\begin{itemize}

\item Fine grained Linux kernel preemptibility does not help prioritizing
the interrupt load from a real-time point of view, which means that low-priority
bottom-halves can still preempt high-priority real-time Linux tasks
(SCHED\_FIFO) under this model, thus introducing unbounded latencies.

\end{itemize}

By implementing a technique called "interrupt shielding"
using ADEOS capabilities, we can control the interrupt flow
so that Linux IRQ handlers are not fired while real-time
RTAI tasks tread on Linux kernel code. This is obtained by
inserting an intermediate ADEOS domain between RTAI and Linux,
and stalling/unstalling this stage at the proper time. This
way, whatever Linux actions are regarding its own interrupt
state, ADEOS guarantees that the effective interrupt control
for the GPOS kernel is left in the hands of the shielding
domain above Linux in the pipeline.

\begin{verbatim}
i.e. IRQ -> [RTAI] -->-- [Shield] -->-- [Linux] (std mode)

     IRQ -> [RTAI] -->-- [Shield] --/   [Linux] (rt mode)
\end{verbatim}

\begin{itemize}

\item Interrupt shielding has one drawback: RTAI tasks which end up
suspending themselves on a Linux kernel resource waiting for a Linux
interrupt to occur (e.g. I/O or timing wait) will be woken up only
after the shield is deactivated, i.e. when no other RTAI task is
running into the Linux kernel domain. This fact is a source of
priority inversions, since low priority RTAI tasks could prevent
hi-priority ones to wake up until they relinquish the processor.
Additionally, Linux's periodic timer resolution is not suitable for
hi-frequency real-time processing.

\end{itemize}

Timing syscalls (\texttt{gettimer()}/\texttt{setitimer()} and \texttt{nanosleep()}) used by
the POSIX layer are transparently intercepted by RTAI/fusion,
and converted to their RTAI-based hard real-time
counterparts. This conversion has two positive effects: RTAI's
timer resolution is much higher, and timed RTAI tasks
are suspended into the RTAI domain, thus cannot be shielded
from timer interrupts by the intermediate domain.

However, RTAI tasks waiting on I/O events only handled by the
Linux kernel are still subject to priority inversions. For
now, the best way to prevent this undesirable side-effect is
to have those tasks handled by RTAI I/O drivers instead of
relying on Linux drivers, since wakeups in the RTAI domain
are performed immediately by the RTAI interrupt handler.

\begin{itemize}

\item RTAI currently provides determinism \emph{aside} of Linux by adding a
preemptive and concurrent kernel. Services requests from RTAI to Linux
then cause the requested services to run outside the real-time
execution domain. RTAI tasks can only send asynchronous requests
(i.e. srqs) to perform Linux services which will be processed when no
real-time tasks are runnable.  Moreover, the service inherits the
scheduling priority of the last Linux task which happened to have been
preempted by RTAI. This situation currently prevents the Linux kernel
code to be part of the real-time execution domain.

\end{itemize}

By tracking the priority of the RTAI task running the Linux
kernel code and applying it dynamically to the Linux
placeholder task controlled by the RTAI scheduler
(i.e. rt\_linux\_task), the position of the RTAI task
within the real-time priority hierarchy is kept unchanged,
even when it executes into the Linux domain.

Additionally, the priority of the Linux task coupled to the
real-time RTAI task is set to a value preserving the overall
RTAI priority scheme.  This way, we have two schedulers
(i.e. RTAI and Linux) cooperating for the execution of
real-time tasks inside a single priority scheme across both
execution domains.

Example: 
\begin{verbatim}
RTAI domain   -- RTAI (pseudo-)task "T0" scheduled by rtai_sched
        (pri = 10)

Linux domain  -- Linux task "foo" (mapped to T0) scheduled by Linux
        (pri = sched_getpriority_max(SCHED_FIFO) + 1 + pri(T0))
\end{verbatim}
\begin{itemize}