4.1 Eingebettete Betriebssysteme
225
können dann oberhalb der zugehörigen Treiber implementiert werden, d.h. nicht
basierend auf einer standardisierten API (siehe Abb. 4.2).
Betriebssystem-Kern
Betriebssystem-Kern
Gerätetreiber
Middleware
Anwendungssoftware
Middleware
Middleware Middleware
Anwendungssoftware
Gerätetreiber Gerätetreiber
Gerätetreiber
Abb. 4.2 Gerätetreiber: (links:) oberhalb und (rechts:) unterhalb des Betriebssystem-Kerns
• Schutzmechanismen sind nicht immer erforderlich, da eingebettete Systeme
oft für einen bestimmten Zweck entworfen werden (es wird nicht angenommen,
dass sie sogenanntes „Multiprogramming” unterstützen). Daher kommt es selten
vor, dass ungetestete Programme geladen werden. Nach dem Testen von Software
könnte davon ausgegangen werden, dass diese zuverlässig ist. Dies trifft genauso
auf die Eingabe und Ausgabe zu. Im Gegensatz zu Desktop-Anwendungen müssen
Ein/Ausgabeoperationen nicht als privilegierte Befehle implementiert werden,
Prozesse dürfen eigenständig Eingaben und Ausgaben vornehmen. Dies passt gut
zum vorher angesprochenen Punkt und senkt den Aufwand für E/A-Vorgänge.
Beispiel 4.1: Sei switch die (in den Speicheradressbereich abgebildete) E/AAdresse eines Schalters, der von einem Programm abgefragt werden soll. Dies
kann einfach mit dem Befehl
register,switch
erfolgen. Es ist nicht notwendig, dafür einen Betriebssystemdienst aufzurufen,
der einen erheblichen Aufwand zum Sichern und Wiederherstellen des Prozesskontextes (Register usw.) erfordern würde.
∇
Es ist aber ein Trend hin zu dynamischeren eingebetteten Systemen feststellbar. Zudem können Sicherheitsanforderungen Schutzvorrichtungen notwendig
machen. Zu diesem Zweck wurden spezielle Speicherschutzeinheiten (engl. Memory Protection Units (MPUs)) entworfen, ein Beispiel dafür findet sich in [164].
Für Systeme mit einer Mischung von kritischen und unkritischen Anwendungen
(engl. mixed-criticality systems) kann ein konfigurierbarer Speicherschutz [353]
ein Ziel sein.
• Unterbrechungen (engl. interrupts) können mit beliebigen Prozessen verbunden werden. Über Betriebssystemdienste können wir anfordern, dass bestimmte
Prozesse gestartet oder beendet werden, wenn eine bestimmte Unterbrechung auftritt. Wir könnten sogar die Startadresse eines Prozesses direkt in der InterruptVektortabelle hinterlegen. Diese Methode ist allerdings sehr gefährlich, da das
Betriebssystem dann nicht darüber informiert wäre, dass dieser Prozess tatsächlich läuft. Darunter könnte auch die Kompatibilität leiden: wenn ein bestimmter
225
können dann oberhalb der zugehörigen Treiber implementiert werden, d.h. nicht
basierend auf einer standardisierten API (siehe Abb. 4.2).
Betriebssystem-Kern
Betriebssystem-Kern
Gerätetreiber
Middleware
Anwendungssoftware
Middleware
Middleware Middleware
Anwendungssoftware
Gerätetreiber Gerätetreiber
Gerätetreiber
Abb. 4.2 Gerätetreiber: (links:) oberhalb und (rechts:) unterhalb des Betriebssystem-Kerns
• Schutzmechanismen sind nicht immer erforderlich, da eingebettete Systeme
oft für einen bestimmten Zweck entworfen werden (es wird nicht angenommen,
dass sie sogenanntes „Multiprogramming” unterstützen). Daher kommt es selten
vor, dass ungetestete Programme geladen werden. Nach dem Testen von Software
könnte davon ausgegangen werden, dass diese zuverlässig ist. Dies trifft genauso
auf die Eingabe und Ausgabe zu. Im Gegensatz zu Desktop-Anwendungen müssen
Ein/Ausgabeoperationen nicht als privilegierte Befehle implementiert werden,
Prozesse dürfen eigenständig Eingaben und Ausgaben vornehmen. Dies passt gut
zum vorher angesprochenen Punkt und senkt den Aufwand für E/A-Vorgänge.
Beispiel 4.1: Sei switch die (in den Speicheradressbereich abgebildete) E/AAdresse eines Schalters, der von einem Programm abgefragt werden soll. Dies
kann einfach mit dem Befehl
register,switch
erfolgen. Es ist nicht notwendig, dafür einen Betriebssystemdienst aufzurufen,
der einen erheblichen Aufwand zum Sichern und Wiederherstellen des Prozesskontextes (Register usw.) erfordern würde.
∇
Es ist aber ein Trend hin zu dynamischeren eingebetteten Systemen feststellbar. Zudem können Sicherheitsanforderungen Schutzvorrichtungen notwendig
machen. Zu diesem Zweck wurden spezielle Speicherschutzeinheiten (engl. Memory Protection Units (MPUs)) entworfen, ein Beispiel dafür findet sich in [164].
Für Systeme mit einer Mischung von kritischen und unkritischen Anwendungen
(engl. mixed-criticality systems) kann ein konfigurierbarer Speicherschutz [353]
ein Ziel sein.
• Unterbrechungen (engl. interrupts) können mit beliebigen Prozessen verbunden werden. Über Betriebssystemdienste können wir anfordern, dass bestimmte
Prozesse gestartet oder beendet werden, wenn eine bestimmte Unterbrechung auftritt. Wir könnten sogar die Startadresse eines Prozesses direkt in der InterruptVektortabelle hinterlegen. Diese Methode ist allerdings sehr gefährlich, da das
Betriebssystem dann nicht darüber informiert wäre, dass dieser Prozess tatsächlich läuft. Darunter könnte auch die Kompatibilität leiden: wenn ein bestimmter