Zentrale Ein/Ausgabe-Unterstützung

In jedem Betriebssystem existiert eine Komponente, die Hardwareressourcen zentral verwaltet, um Konflikte bei Zugriffen zu vermeiden. Wie aus Tab. 3.1 erkenntlich ist, sollten auch die Programmierung des Interrupt-Controllers sowie PCI-Bus-Zugriffe zentral gekapselt sein.

Würde man jeder Treiberinstanz wahlfreien Zugriff gestatten, wären Konflikte vorprogrammiert, da viele Operationen nicht atomar (also inherent sequentiell) durchführbar sind und mehrere Schritte benötigen.

Ein Beispiel ist die Konfiguration eines Gerätes am PCI-Bus. Hierbei werden nacheinander zwei 32-Bit Ports -- Adreß- und Datenport -- genutzt: 1. Geräteregister addressieren durch Schreiboperation in Adreßport und 2. Konfigurationsregister lesen/schreiben durch Lese/Schreiboperation auf Datenport.

Im DROPS DDE ist die benötigte Komponente der I/ O Server:

Ressourcenverwaltung

Der I/ O Server erlaubt es, Ressourcen anzufordern und freizugeben. Zugriffe auf nicht zugewiesene Ressourcen sind nicht erlaubt.
Obwohl diese Komponente unabhängig von den tatsächlich verwendeten Gerätetreibern ist, habe ich hier die Schnittstelle von Linux übernommen, da sie genügend abstrakt bzw. allgemeingültig ist, um auch Linux-fremde Treiber unterstützen zu können.

PCI Support

Der PCI-Bus-Zugriff bzw. der Zugriff auf den PCI Configuration Space wird hinter einer abstrakten Schnittstelle verborgen, die es erlaubt synchronisierte gerätespezifische Konfigurationen durchzuführen.
Auch hier war Linux das Vorbild.

Interrupt-Controller

Bestandteil des I/ O Servers ist eine zentralisierte Interruptlogik-Behandlung, welche die Zustellung von Interrupts per IPC anbietet. Dieses Konzept wurde 1:1 aus [LH00] übernommen.

Ein Vorteil des I/ O Servers ist die Möglichkeit, systemweite Politiken für Ressourcen mit Hilfe einer zentralen Instanz durchzusetzen. Ich gehe hier aber nicht näher auf diese Möglichkeit ein, da für DROPS noch kein Sicherheitskonzept entwickelt wurde und dieses nicht Gegenstand der Arbeit sein soll.

Abbildung 3.1: Aufbau des I/ O Servers

Dieser Entwurf ist ein I/ O Server mit dem in Abb. 3.1 dargestellten Aufbau. Die Schnittstellen werden von zwei Threads zur Verfügung gestellt, die sich beim Namensdienst als ioserver und omega0 registrieren. Im Omega0-Teil ist der weitere Ablauf und das Threading wie in [LH00] beschrieben. Auf der anderen Seite erfüllt der ioserver-Thread Anfragen betreffend Ressourcen-Management und PCI.

Eine weitere Aktivität innerhalb des Servers ist ein Timer, welcher mit Hilfe der Zeitangabe des Mikrokerns einen Timer-Tick auf der IO Info Page zur Verfügung stellt. Diese Informations-Seite wird jedem Klienten während der Initialisierung eingeblendet und unterstützt eine DDE-weite Zeitbasis.

Der I/ O Server stützt sich außerdem auf Funktionalitäten des Common L4 Environment und beinhaltet deshalb auch dessen lokale Umgebung.