Embedded-Betriebssysteme
Linux: Embedded für alle
Fortsetzung des Artikels von Teil 1
Echtzeit: erweitert oder eingepflanzt
Mit „Single-Kernel“ wird die ursprünglich als unmöglich angesehene Vorgehensweise bezeichnet, Linux nachträglich mit Echtzeit-Eigenschaften auszurüsten. „Dual-Kernel“ bedeutet, dass ein kleiner Echtzeit-Kernel (so genannter Nano-Kernel) Linux vorangestellt wird, der die echtzeit-pflichtigen Aufgaben wahrnimmt, während der Linux-Kernel nur dann Rechenzeit erhält, wenn der Nano-Kernel in der Warteschleife läuft. Typische „Dual-Kernel“-Systeme sind z.B. RTAI, RTLinux, RTCore und Xenomai. Die Linux-Erweiterungen, mit denen ein „Single-Kernel“-Echtzeit-System erzeugt werden kann, werden „PREEMPT_RT-Patch“ genannt. Dieser Name leitet sich von der früheren Form der Konfigurations-Variablen CONFIG_PREEMPT_RT ab, mit der die Echtzeit-Fähigkeit bei der Herstellung des Linux-Kernels eingeschaltet wurde.
Industrietaugliche „Dual-Kernel“-Systeme waren relativ kurzfristig bereits ab 2002 verfügbar und haben sicher einen großen Anteil daran, dass Linux bereits zu diesem Zeitpunkt als sehr attraktiv für Embedded-Systeme angesehen wurde. Der Grund für die relativ rasche Verfügbarkeit lag darin, dass das Funktionsprinzip schon lange bekannt war und auf anderen Systemen wie z.B. DOS und Windows bereits eingesetzt wurde. Nachteil dieses Verfahrens ist aber, dass Linux für diesen Zweck angepasst werden muss und dass diese Anpassungen niemals in den offiziellen Mainline-Linux-Kernel aufgenommen würden.
Die Entwicklung des „Single-Kernel“-Echtzeit-Linux gestaltete sich etwas schwieriger. In einem ersten Schritt mussten sämtliche potentiellen Latenzquellen lokalisiert und Umgehungsmechanismen dafür gefunden werden. Eines der größten Probleme war dabei die so genannte Prioritäts-Inversion, die auftritt, wenn ein Prozess mit hoher Priorität Zugriff auf eine nur einmalig im System vorhandene Ressource benötigt, die von einem Prozess mit niedrigerer Priorität belegt und dadurch gesperrt wird. In einem solchen Fall wird dem höher priorisierten Prozess die niedrigere Priorität aufgezwungen, wodurch eine wesentliche Eigenschaft eines prioritäts-gesteuerten Echtzeit-Systems verlorengeht.
Eine der Methoden, um Prioritäts-Inversion zu verhinden, stellt Prioritäts-Vererbung („Priority Inheritance“, abgekürzt „PI“) dar. Bei diesem Verfahren erhält der blockierende Prozess vorübergehend die Priorität des höher priorisierten Prozesses, so dass das kritische Code-Segment mit seiner eigenen Priorität durchlaufen wird. Das eigentliche Problem bestand aber darin, dass Linus Torvalds die Aufnahme von PI in den Mainline-LinuxKernel zunächst abgelehnt hat. Denn es war bereits damals unumstritten, dass ohne eine effiziente Maßnahme zur Verhinderung von Prioritäts-Inversion niemals ein befriedigendes Echtzeit-Verhalten erreicht werden kann.
Jobangebote+ passend zum Thema
Erst auf dem - deshalb legendären - Kernel-Summit in Ottawa im Jahre 2006 hat Linus Torvalds der Aufnahme von PI-Mutexen zugestimmt und damit den Weg frei gemacht für den kontinuierlichen Einbau der Echtzeit-Komponenten in den Linux-Kernel. Diese Komponenten sind jeweils in einem Patch zusammengefasst; an der Größe der Patches (Bild 2) lässt sich deren kontinuierliche Übernahme in den Mainline-Kernel erkennen: Von anfänglich 1,56 Mbyte konnte der Patch inzwischen auf 750 Kbyte reduziert werden. Deutlich ist aber auch sichtbar, dass zwischendurch neue Komponenten hinzugefügt werden mussten, von denen die meisten durch die Weiterentwicklung des Kernels bedingt waren.
Der Ausreißer bei der Version 2.6.29.6-rt24 hängt damit zusammen, dass hier ausnahmsweise sehr viele Komponenten bereits enthalten waren, die für die folgende Mainline-Version vorgesehen waren. An dieser Abbildung ist nicht zu erkennen, dass weit über ein Drittel der verbliebenen 750 Kbyte bereits für die Übernahme nach
Mainline vorbereitet ist, so dass in den nächsten Versionen eine weitere deutliche Größen- reduktion des PREEMPT_RT-Patch zu erwarten ist, was natürlich die zukünftige Pflege und Integration wiederum sehr erleichtern wird.
Bei Performance-Messungen von Echtzeit-Systemen spielt die maximale Latenz des Systems eine wichtige Rolle. Diese Variable bezeichnet die Zeitdauer vom Eintreffen eines nicht vorhersagbaren, also asynchronen externen Ereignisses bis zu dessen Bearbeitung durch das System. Diese Bearbeitung kann bereits im Treiber (Interrupt-Latenz) oder erst in einem Userspace-Programm (Gesamt-Latenz) erfolgen. Die Interrupt-Latenz ist zwar immer kürzer als die Gesamt-Latenz, aber die Bearbeitung im Treiber ist programmtechnisch schwieriger und nicht portabel; außerdem gestaltet sich die Fehlersuche komplizierter als im Userspace.
Als weiterer wichtiger Nachteil ist zu beachten, dass bei einem Fehler im Treiber das gesamte System in Mitleidenschaft gezogen werden kann, während bei der Programmierung im Userspace nur die jeweilige Applikation betroffen ist und das System stabil bleibt. In jedem Fall sollte bei der Evaluation verschiedener Echtzeit-Systeme in Bezug auf deren Latenz darauf geachtet werden, dass nur gleiche Variablen miteinander verglichen werden. Die Interrupt-Latenzen von „Single-Kernel“- bzw. „Dual-Kernel“-Systemen unterscheiden sich z.B. nicht wesentlich, und in beiden Fällen lassen sich auf modernen, dafür geeigneten Prozessoren Latenzwerte im einstelligen Mikrosekundenbereich erreichen.
Mit den genannten Methoden lässt sich also ein echtzeitfähiges Linux herstellen, das den Vergleich mit klassischen Echtzeit-Kerneln nicht zu scheuen braucht, was mit zahlreichen erfolgreichen Industrieprojekten bewiesen wurde. Damit wurde auch die zweite Hürde genommen
- Linux: Embedded für alle
- Echtzeit: erweitert oder eingepflanzt
- Zertifizierung
