Merge branch 'master' of ssh://tglx.de/home/linutronix/git/schulung

1 files changed, 162 insertions, 6 deletions

diff --git a/realtime/rt-basics/handout_rt-basics_de.tex b/realtime/rt-basics/handout_rt-basics_de.tex
index 4c391b2..8d98ccc 100644
--- a/realtime/rt-basics/handout_rt-basics_de.tex
+++ b/realtime/rt-basics/handout_rt-basics_de.tex
@@ -1,17 +1,173 @@
-\documentclass{article}
+\documentclass{lxarticle}
 \usepackage{german}
 \usepackage[utf8]{inputenc}
+\usepackage{lxheaders}
+\usepackage{lxextras}
 
 \begin{document}
 
-\section*{Titel}
+\section*{Realtime Linux}
 
-\subsection*{Abschnitt1}
+\subsection*{Grundlagen}
 
-Text
+\subsubsection*{Was ist Echtzeit?}
+Vor der Betrachtung verschiedener Ansätze, Linux echtzeitfähig zu machen, ist es
+notwendig, einige grundlegende Begrifflichkeiten zur erläutern:
+\begin{itemize}
+\item Echtzeit:
+Zur Definition eines Echtzeitsystems kann man folgende Aussagen Treffen: Auf
+einem Echtzeitsystem hängt die Korrektheit einer Berechnung nicht nur von ihrer
+logischen Korrektheit, sondern auch von der Ausführung zum korrekten Zeitpunkt
+ab. Das Nichteinhalten eines bestimmten Zeitrahmens resultiert in einem Fehler.
+\item Latenzzeit: Unter Latenzzeit versteht man den Zeitraum zwischen dem
+Auftreten eines Events und der Reaktion auf dieses Event.
+\item Jitter: Mit Jitter bezeichnet man die Varianz der Latenzzeit.
+\end{itemize}
 
-\subsection*{Abschnitt2}
+\subsubsection*{Anwendungsbereiche}
+Die wohl gängigsten Anwendungsbereiche für Echtzeitsysteme sind die
+Steuerungs- und Automatisierungstechnik, Multimediasysteme und die Luft- und
+Raumfahrttechnik. Ein weiteres interessantes Einsatzgebiet stellt die 
+Finanzdienstleistung dar. Hier geht es insbesondere um die zeitgenaue,
+zuverlässige Abwicklung von Finanztransaktionen über hochverteilte Systeme.
 
-Text
+\subsubsection*{Anforderungen an ein Echtzeitsystem}
+Ein Echtzeitsystem muß in der Lage sein, in einem garantierten Zeitrahmen auf
+ein Ereignis zu reagieren. Es muß also möglich sein, in möglichst kurzer Zeit
+von einer niederprioren Task auf eine hochpriore Task umzuschalten, falls diese
+Rechenzeit benötigt. Das System muß also möglichst ''feingranular''
+unterbrechbar sein.
+Doch allein die Unterbrechbarkeit kann kein deterministisches Zeitverhalten
+garantieren. So kann eine niederpriore Task Resourcen blockieren, die von einer
+hochprioren Task benötigt werden. Wird die niederpriore Task nun unterbrochen,
+kommt es zur ''Prioritätsinversion / priority inversion'', da die hochpriore Task
+auf die Freigabe der Resource wartet, diese aber erst wieder dann freigegeben
+wird, wenn die niederpriore Task wieder Rechenzeit bekommt.
+Gelöst werden kann dieses Problem durch ''prioriy inheritance'' und ''priority ceiling''.
+\begin{itemize}
+\item Prioritätsvererbung / priority inheritance: Hier wird die Priorität der
+niederprioren Task angehoben, um zu erreichen, daß die blockierte Resource
+freigegeben werden kann.
+\item Prioritätsgrenzen / priority ceiling: Hier wird für jede Resource eine
+Prioritätsgrenze festgelegt. Jede Task, die die Resource belegt, wird auf die
+Prioritätsgrenze der Resource angehoben.
+\end{itemize}
+
+\subsection*{Realtime Linux Varianten}
+\subsubsection*{Historisches zu Echtzeitlinux}
+Im Gegensatz zu traditionellen Echtzeitsystem wurde Linux ursprünglich nicht als
+solches designt. Als General Purpose Operating System wurde Linux auf Fairness
+und Durchsatz optimiert. Linux echtzeitfähig zu machen, bedeutet also, ein
+Standardbetriebssystem um Echtzeitfunktionen bzw. entsprechende Sonderfälle zu
+erweitern. Mit dieser Tatsache lassen sich die zwei technischen Ansätze für
+Realtime Linux erklären.
+\begin{itemize}
+\item Dual Kernel Ansatz: Hier koexistieren ein Echtzeitkernel, der für alle
+zeitkritischen Dinge zuständig ist, und ein Standard Linux Kernel. Dieser Ansatz
+setzt voraus, daß alle externen Events zuerst vom Echtzeitkernel bearbeitet
+werden, bevor Sie an den Linux Kernel weitergereicht werden können. Die
+bekanntesten Vertreter dieser Technik sind RTAI und Xenomai.
+\item In-Kernel Ansatz: Diese Methode macht Linux an sich zu einem
+Echtzeitsystem. Dieser Ansatz wird mit dem Realtime Preemption Patch verfolgt
+und ist die Variante, die von den Linux Entwicklern zur Integration in den
+Hauptzweig von Linux abgenickt wurde.
+\end{itemize}
+
+\subsubsection*{RTAI}
+Das Realtime Application Interface (RTAI) ist eine Entwicklung der Technischen
+Universität Mailand und entstand unter der Schirmherrschaft von Professor Paolo
+Mantegazza. Oberstes Designziel von RTAI ist und war es, die kleinstmöglichen
+Latenzzeiten auf einer gegebenen Hardwareplattform zu erzielen. Dieses
+Designziel bedingt diverse Einschränkungen für RTAI Applikationen. Weiterhin
+wird nur eine recht kleine Anzahl an Zielplattormen unterstützt (derzeit x86,
+x86\_64 und diverse ARM Plattformen).
+\begin{figure}[h]
+\centering
+\includegraphics[height=0.5\textwidth]{images/rtai.png}
+\caption{Technischer Aufbau von RTAI}
+\label{img:rtai}
+\end{figure}
+RTAI ist ein typischer Vertreter des Dual Kernel Ansatzes. Abbildung
+\ref{img:rtai} zeigt die Funktionsweise von RTAI.
+
+\subsubsection*{Xenomai}
+Das Xenomai Projekt wurde im Jahre 2001 gegründet. Im Gegensatz zu RTAI erlaubt
+Xenomai auch Echtzeit im Userpace (RTAI erlaubt dies nur sehr eingeschränkt).
+Die Besonderheit von Xenomai sind die sogenannten Skins, die es vereinfachen sollen,
+Applikationen von anderen Echtzeitsystemen nach Xenomai zu portieren.
+Xenomai Skins bilden die API dieser Systeme ab. Xenomai unterstützt derzeit
+folgende Architekturen: PowerPC32, PowerPC64, x86, x86\_64, Blackfin, ARM und
+ia64). Die zentralen Begriffe im Designkonzept von Xenomai stellen Xenomai
+Nucleus, die Interrupt Pipeline (IPIPE), Hardware Abstraction Layer (HAL) und
+System Abstraction Layer (SAL) dar.
+IPIPE kann bildlich als virtueller Interruptkontroller betrachtet werden.
+Sie organisiert das System in verschiedenen Domains. Interrupts werden von
+IPIPE entgegengenommen und an die einzelnen Domains verteilt.
+Nucleus beeinhaltet die Xenomai Core Funktionalität. Dieser ist zuständig dafür,
+alle notwendigen Resourcen bereitzustellen, die Skins benötigen, um die Funktionalität
+von RTOSsen nachbilden zu können. Der Hardware Abstraction Layer beinhaltet
+den Plattform und CPU abhängigen Code. Alle darüberliegenden Layer (darunter auch Nucleus)
+bauen darauf auf. HAL ist kombiniert mit dem System Abstraction Layer. Dieser
+soll die darüberliegenden Layer, wie z.B. Nucleus, noch portierbarer machen.
+Abbildung \ref{img:xenomai} zeigt das technische Zusammenspiel der Xenomai
+Komponenten. Abbildung \ref{img:ipipe} zeigt die Funktionsweise von IPIPE.
+\begin{figure}[h]
+\centering
+\includegraphics[height=0.5\textwidth]{images/xenomai.png}
+\caption{Technischer Aufbau von Xenomai}
+\label{img:xenomai}
+\end{figure}
+\begin{figure}[h]
+\centering
+\includegraphics[height=0.5\textwidth]{images/ipipe.png}
+\caption{Technische Funktionsweise von IPIPE}
+\label{img:ipipe}
+\end{figure}
+
+\subsubsection*{Preempt RT}
+Der Realtime Preemption Patch entstand ursprünglich aus Arbeiten von Ingo Molnar
+und Thomas Gleixner. Beide sind bis zum heutigen Zeitpunkt die treibenden Kräfte
+bei der Entwicklung von Preempt RT.
+Im Gegensatz zu RTAI und Xenomai macht Preempt RT den Linux Kernel an sich
+echtzeitfähig. Dies wird im Besonderen durch folgende Mechanismen erreicht:
+\begin{itemize}
+\item Sleeping Spinlocks: Spinlocks werden durch RT Mutexe ersetzt. Raw
+Spinlocks ersetzen die Eigenschaft der ursprünglichen Spinlocks.
+\item Threaded Interrupt Handlers: Interrupt Handler laufen per Default nicht im
+harten Interruptkontext, sondern als Kernelthread.
+\end{itemize}
+Viele Mechanismen, die ursprünglich in Preempt RT entwickelt wurden, haben
+bereits Ihren Weg in den Mainline Linuxzweig gefunden: High Resolution Timer
+(Hochauflösende Timer unabhängig vom Scheduler Tick), Priority Inheritance,
+generisches Interrupthandling für alle Architekturen und mit 2.6.30 nun auch die
+Threaded Interrupt Handler.
+Weiterhin hat sich die Linux Entwicklergemeinde bereits 2006 darauf geeinigt,
+daß Preempt RT in den Linux Kernel integriert wird. Weiterhin bietet der
+Realtime Preemption Patch den großen Vorteil, daß Echtzeitapplikationen als POSIX
+Realtime Applikationen geschrieben werden. Es wird keine spezielle API
+verwendet. Preempt RT Unterstützt eine Vielzahl von Architekturen (PowerPc, x86,
+x86\_64, MIPS, ARM, ...).
+\begin{figure}[h]
+\centering
+\includegraphics[height=0.5\textwidth]{images/preempt_rt.png}
+\caption{Überblick Preempt RT}
+\label{img:preempt_rt}
+\end{figure}
+Wie Abbildung \ref{img:preempt_rt} zeigt, integriert Preempt RT die
+Echtzeitfunktionalität ''nahtlos'' in den Linux Kernel. Auch die Entwickler
+anderer Projekte haben die Vorzüge von Preempt RT bereits erkannt. Die Roadmap
+für Xenomai 3 sieht Preempt RT Support vor. Dies würde den Einsatz von Xenomai
+Skins auf Preempt RT Kerneln ermgöglichen.
+
+\subsection*{Kontrollfragen}
+
+\begin{enumerate}
+\item Was sind die wichtigsten Anforderungen an ein Echtzeitsystem?
+\item Welche beiden Ansätze gibt es, um Linux echtzeitfähig zu machen?
+\item Was sind die bekanntesten Vertreter für Echtzeitlinux und welche der oben
+beschriebenen Ansätze verfolgen Sie?
+\item Wird für das Schreiben einer Echtzeitapplikation mit Preempt RT eine
+spezielle API benötigt?
+\end{enumerate}
 
 \end{document}