Einführende Betrachtung des USB und Möglichkeiten der Integration in das Rainbow-Betriebssystem
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Einführende Betrachtung des USB und Möglichkeiten der
Integration in das Rainbow-Betriebssystem
Georg Gottleuber
Institut für Verteilte Systeme
Universität Ulm
Albert-Einstein-Allee 11
89069 Ulm
georg.gottleuber@uni-ulm.de
ABSTRACT
Diese Ausarbeitung führt in die Funktionsweise und Hard-
ware des Universal Serial Bus (USB) ein. Dabei werden die
einzelnen Spezifikationen, die verwendete Hardware, die zu-
grundeliegende Logik und die benötigten Treiber skizziert.
Außerdem werden verschiedene Architekturmöglichkeiten
für die USB-Treiberimplementierung in das transaktionale
verteilte Betriebssystem Rainbow besprochen.
Keywords
USB, Rainbow, transaktionale Treiber
1. EINFÜHRUNG
Der Universal Serial Bus (USB) findet seit seiner Einführung
in der ersten Version 1995 im Desktop-, Embedded- und Figure 1: Physikalische Bus-Topologie (Abbildung
Servermarkt eine weite Verbreitung. Die Stecker und Buch- aus [2])
sen sind an nahezu all diesen Geräten zu finden. Die gängi-
gen Betriebssysteme Windows, Mac OS, Linux und BSD
unterstützen die Verwendung von USB durch entsprechende fünf herkömmliche Hubs untereinander verwendet werden.
Treiber. Verbundgeräte, die mehrere Funktionen anbieben (z.B.:
Drucker und Scanner) können dann jedoch nicht auf der
Das an der Universität Ulm entwickelte transaktionale untersten Ebene benutzt werden, da sie zwei Ebenen benöti-
verteilte Betriebssystem Rainbow verwendet PCs, die eben- gen.
falls USB-Hardware enthalten. Für die transaktionale Un-
terstützung der USB-Treiber werden verschiedene Ansätze 2.2 Spezifikationen
erläutert, die von Michael Rupp [8] erarbeitet wurden. Die Version 1.0 der USB-Spezifikation erschien 1995 und
damit im gleichen Jahr wie Apples IEEE 1394 Firewire-
2. USB Standard. Ausgearbeitet von den Firmen Compaq, Dig-
2.1 Topologie ital Equipment Corporation, IBM PC Company, Intel,
Der USB verbindet USB-Geräte mit dem USB-Host. Die Microsoft, NEC und Northern Telecom sollte USB eine
physikalischen Verbindungen können in mehreren Ebe- schnelle, bidirektionale, günstige, dynamisch an- und ab-
nen sternförmig angeordnet werden (siehe Abbildung 1). steckbare, serielle Schnittstelle schaffen [1]. Als weitere
Verzweigungen werden durch sogenannte Hubs realisiert. Merkmale werden selbstidentifizierende Peripheriegeräte,
Wegen Zeitvorgaben können höchstens sieben Ebenen automatische Treiberauswahl und Konfiguration, Expansion
verwendet werden. Da die Anschlüsse des Hosts be- der PC-Anschlussmöglichkeiten auf bis zu 127 Geräte, er-
reits als Root-Hub implementiert sind, können maximal weiterbare Architektur und einfach zu handhabende gün-
stige Verkabelung genannt. Die Spezifikation beschreibt alle
grundlegenden Eigenschaften von USB, wie Bus-Topologie,
Kommunikationsfluss, Transferstypen, mechanische und
elektrische Eigenschaften, Hardware-Software-Interaktion
und USB-Hubs (jeweilige Erläuterung im restlichen Doku-
ment). Als grundsätzliches Design wurde ein Master-Slave-
Bus mit dem PC als festen Busmaster (Host) gewählt.
Für Anwender sind besonders die zwei Geschwindigkeits-
modi interessant. Die Übertragung im LowSpeed-Modus er-reicht eine Bruttodatenrate von 1,5 MBit/s. Im FullSpeed-
Modus werden bis zu 12 MBit/s übertragen. Die für den
Anwender maximal nutzbare Datenrate ergibt sich durch
Abzug des protokollbedingten Overheads von der Brutto-
datenrate.
Als Verkabelung werden ungedrillte und ungeschirmte Ka-
bel mit einer Maximallänge von 3 Metern für LowSpeed-
Anwendungen (z.B.: Maus und Tastatur), sowie verdrillte
und geschirmte Kabel mit bis zu 5 Metern Länge für den
FullSpeed-Betrieb vorgeschrieben.1
Die folgende Version 1.1 beseitigte einige Unklarheiten und
führte Interrupt-OUT-Transfers (Abschnitt 2.4.2 und 2.4.4)
neu ein.
Mit der USB-Spezifikation in Version 2.0 wurde ein
HighSpeed-Modus eingeführt, der eine Bruttoübertragun-
srate von bis zu 480 Mbit/s ermöglicht. Dabei wer-
den die bisherigen FullSpeed-Verbindungskabel verwendet.
Der Funktionalität von USB 1.x2 Geräten bleibt un-
berührt. Außerdem können diese Geräte ohne unnötigen
Geschwindigkeitsverlust an USB-2.0-Hubs betrieben wer-
den. Ebenfalls können USB-1.x-Hubs in die Topologie inte-
griert werden. Unterhalb eines solchen Hubs ist dann jedoch Figure 2: USB 3.0 Dual-Bus-Architektur (Abbil-
keine HighSpeed-Übertragung möglich. dung aus [3])
Die Ende 2008 erschienene Version 3.0 der USB-
Spezifikation beschreibt einen SuperSpeed-Modus, der bis • Stromversorgung: SuperSpeed-Geräte dürfen (bei un-
zu 5 Gbit/s Daten transferiert. Dafür werden jeweils veränderter Versorgungsspannung von 5 V) nach einer
zum Senden und zum Empfangen ein neues Aderpaar ver- erfolgreichen High-Power-Anfrage bis zu 900 mA
wendet (differenzielle Übertragung). Als Konsequenz da- Strom verbrauchen (USB 2.0 nur 500 mA). Ohne An-
raus mussten neue Steckverbinder und entsprechende Ka- frage dürfen 150 mA bezogen werden (USB 2.0 nur 100
bel eingeführt werden. Die SuperSpeed-Transfers verwen- mA).
den nur die neuen Aderpaare, während USB-2.0-Transfers
nur über die bisherigen verlaufen. Die gleichzeitige Verwen- • Idle-Pakete: Wie bisher führen die Verbindungen des
dung von USB-3.0- und USB-2.0-Adern bleibt allein Hubs USB kein extra Taktsignal. Alle angeschlossenen
vorbehalten (siehe Abschnitt 2.6). Die neuen Buchsen sind Geräte halten den Takt, indem sie spezielle Synchro-
aber abwärtskompatibel zu USB-2.0-Kabeln und Geräten. nisationssignale auf den Datenleitungen nutzen. Um
den Takt trotz der erhöhten Geschwindigkeit von USB
Neben dem bestehenden USB-2.0-System wurde so quasi 3.0 zu halten, werden kontinuierlich Pakete versendet.
eine parallele SuperSpeed-Infrastruktur mit eigenem Pro- Wenn eine SuperSpeed-Verbindung keine regulären
tokoll geschaffen. Dieses Protokoll unterscheidet sich jedoch Pakete überträgt, werden Idle-Pakte übertragen. Um
nur in Einzelheiten, sodass die bisherigen hardwareunab- unnötigen Stromverbrauch zu vermeiden, wird ein
hängigen Treiber mit wenigen Modifikationen weiter verwen- weitgehendes Power-Management eingeführt.
det werden können. In einem USB-3.0-Bus bleiben durch
die beschriebene “Dual-Bus-Architektur” USB-2.0-Geräte • Senkung des Stromverbrauchs: Das neue Power-
uneingeschränkt benutzbar [3] (Abbildung 2). Außerdem Management definiert neben dem Übertragungszus-
werden folgende Neuerungen für den SuperSpeed-Modus tand (“Operational”) noch drei weitere Standby- und
genannt [5],[6]: Suspend-Zustände, die auch für Hubs zur Verfügung
stehen. Ein Hub kann beispielsweise in einen Standby-
Zustand wechseln, wenn alle an ihn angeschlossenen
• Dual-Simplex-Unicast-Bus: Während USB 2.0 ein Geräte ebenfalls in einem Energiesparzustand sind.
Half-Duplex-Broadcast-Bus zugrunde liegt, arbeitet
• Kein Polling: Das bisher strikte Polling wird durch
SuperSpeed als Dual-Simplex-Unicast-Bus. Dadurch
die Einführung einer neuen asynchronen Nachricht ver-
ist es möglich gleichzeitig IN- und OUT-Transaktionen
mieden. So muss der Host nun beispielsweise nicht
durchzuführen.
mehr ständig bei der USB-Tastatur nachfragen, ob
1 neue Nutzereingaben vorhanden sind. Stattdessen
In den späteren Spezifikationen wurden die Län- frägt er einmal, worauf die Tatstatur mit NRDY (“Not
genbeschränkungen wieder aufgehoben und nur noch die
notwendigen elektrischen Eigenschaften und maximalen Sig- Ready”) antwortet. Daraufhin entfallen weitere An-
nallaufzeiten vorgegeben. fragen, da die Tastatur, sobald sie neue Eingaben
2
Mit dieser Schreibweise werden USB 1.0 und USB 1.1 kon- bekommt ein ERDY (“Endpoint Ready”) sendet. Nun
forme Geräte zusammengefasst. frägt der Host mit der Gewissheit, dass neue Datenvorhanden sind nach. Als Antwort erhält er vom Gerät Host Gerät
die neuen Daten. 1 2
• Data-Bursts: Data-Bursts erlauben es dem Host oder
Gerät bis zu 16 DATA-Pakete zu senden, ohne auf eine
4 3 2 1 4 3
Bestätigung (“ACK”) zu warten. Dadurch wird der
Protokoll-Overhead wesentlich reduziert. Typ A Typ B
• Scrambling: Um elektromagnetische Störungen durch 5 43 2 1 5 4321
sich wiederholende Datenmuster bei der Übertra-
gung zu minimieren, werden die Daten mit einem
pseudozufälligen Zahlenstrom mittels XOR vermengt Mini-A Mini-B
(Methode wie bei PCIe 2.0).
5 43 2 1 5 43 2 1
Abzüglich des Protokoll-Overheads kann der Anwender laut
Spezifikation so eine Nettodatenraten von ca. 400 MB/s Micro-AB Micro-B
nutzen.
Alle weiteren Ausführungen beziehen sich, wenn nicht ex-
plizit anders gekennzeichnet, auf die USB-2.0-Spezifikation.
2.3 Hardware
Typ A
In Version 1.0 von USB waren ursprünglich nur eine Typ-A-
Buchse für den Host und eine Typ-B-Buchse für das Gerät Typ B
beschrieben.3 Verbunden wurde der Host mit dem Gerät
mittels einem Kabel welches einen A-Stecker auf einen B-
Stecker führte. Da nur diese Sorte von Kabeln verfüg-
bar war, konnte es nicht passieren, dass versehentlich zwei Micro-AB Micro-B
Geräte oder zwei Hosts miteinander verbunden wurden.
Figure 3: USB-Anschlüsse: USB 1.x und 2.0 in grau,
Wegen des großen Platzbedarfs der Buchsen bei zunehmend USB 3.0 in blau (USB 2.0 aus [4])
kleiner werdenden Geräten, wurden Mini-A- und Mini-B-
Buchsen eingeführt und Verbindungskabel mit A- auf B-
Stecker beider Größen hergestellt. 2.4.2 Endpunkte
Jedem Gerät wird vom Host-Controller eine eindeutige
Für noch kleinere Geräte wurden später Micro-B-Buchsen Adresse zwischen 1 und 127 zugewiesen. Außerdem kann
und entsprechende Kabel realisiert. Allerdings sollten jedes Gerät unabhängig voneinander nutzbare Endpunkte
nun Geräte auch ohne einen PC untereinander USB- anbieten. Endpunkte werden als IN-Endpunkte bezeichnet,
Verbindungen benutzen können. Als Beispiel kann hier wenn sie die Kommunikation zum Gerät ermöglichen. Als
eine direkte Verbindung der Digitalkamera mit einem Fo- OUT-Endpunkte benennt man Endpunkte, die zur Kom-
todrucker dienen. Diese Funktionalität wird USB On-The- munikation zum Host dienen. Minimal muss jedoch ein
Go (OTG) bezeichnet. Eines der beiden Geräte übernimmt Endpunkt Null, der zur Konfiguration benötigt wird, un-
dann die Host-Rolle. Diese OTG-Geräte wurden mit einer terstützt werden. Dieser IN-/OUT-Endpunkt bietet einen
Micro-AB-Buchse ausgestattet, weil sie beide Rollen ein- kombinierten Betrieb [8].
nehmen können. Bei einer solchen Verbindung muss nur
ein Gerät OTG beherrschen, welches zum Host wird [9].
Abbildung 3 zeigt die üblichen und standardisierten USB- 2.4.3 Pipes
Anschlüsse. Um besonders bei den Typ-A-Buchsen Ver- Eine Pipe stellt die Verbindung zwischen deinem Endpunkt
wechslungen zwischen USB 3.0 und den älteren Varianten eines Gerätes und der Software des Hosts dar. Außerdem
auszuschließen, wird von der USB-3.0-Spezifikation eine Far- werden Pipes mit der Datenbandbreite assoziiert. Die meis-
bkodierung in blau vorgeschlagen. ten Pipes werden bei der Konfiguration eines USB-Gerätes
angelegt. Es gibt zwei verschiedene Pipe-Typen.
2.4 Logischer Aufbau
Stream-Pipes sind unidirektional und werden zum Daten-
2.4.1 Frames und Micro-Frames transfer benutzt. Die Struktur, der transportierten Daten
USB verwendet bei der Einteilung der Bandbreite eine Zeit- ist nicht spezifiziert. Stream-Pipes bieten Interrupt-, Bulk-
einheit von 1 ms (USB 1.x) als sogenannten Frame bzw. und Isochronous-Transfers.
125 µs (USB 2.0) als Micro-Frame. Bestimmten Transfer-
typen kann so eine kontinuierliche Bandbreite und Latenz Message-Pipes sind im Gegensatz dazu bidirektional und
zugesichert werden. übertragen spezifizierte Datenstrukturen. Sie werden für
3
Stecker und Buchsen mit der Bezeichnung A werden immer Control-Transfers genutzt und folgen einem speziellen In-
auf Hostseite verwendet. Die Bezeichnung B kennzeichnet teraktionsschema. Zu erst wird vom Host ein Request
immer die Geräteseite. (siehe Abschnitt 2.5.2) an das Gerät geschickt. Darauf folgtTransfers Transfer
Transaktionen Transaktion T1 Transaktion T2 Transaktion T3
Token Paket Daten Paket Handshake Paket
Pakete
PID Adresse Endpunkt CRC PID Daten CRC PID
Pakete auf USB ... SOF T T T1 T T unbenutzt SOF T T2 ...
Start-of-Frame-Paket Transaktionen
Zeit Micro-Frame
Figure 4: Logische Ebenen eines Transfers (abgeändert aus [8])
ein Datentransfer in die gewünschte Richtung. Nach einer eine zugesicherte Bandbreite und Latenz. Sie besitzen keine
Zeitverzögerung folgt dann ein Statusbericht. Eine beson- Fehlerkorrektur und kein Handshake-Paket, da auftretende
dere Message-Pipe, die sogenannte Default-Control-Pipe, ex- Fehler toleriert werden. Als Einsatzgebiete sind Audio- und
istiert immer, sobald ein Gerät angeschlossen ist. Sie gibt Video-Streams angedacht.
Zugriff auf die Gerätekonfiguration, den Status und Kon-
trollinformation [2]. 2.4.5 Transaktionen
Ein USB-Transfer besteht aus verschiedenen Transaktio-
2.4.4 Transfers nen. Während Transfers über verschiedene (Micro-)Frames
Ein Transfer wird durchgeführt, wenn eine Software eine verteilt sein können, müssen USB-Transaktionen innerhalb
Funktion des USB-Gerätes nutzt, z.B. Daten kopiert. Eine eines (Micro-)Frames abgehandelt werden.[8]
Charakterisierung des Datenflusses wird dabei durch vier
verschiedene Transfertypen vorgegeben: 2.4.6 Pakete
Die verschiedenen Pakete einer Transaktion setzen sich
Control-Transfers müssen von jedem USB-Gerät unterstützt üblicherweise aus einer Paket-ID (PID), Daten und einem
werden. Sie dienen der Konfiguration, dem Auslesen von CRC zusammen. Hiervon ausgenommen sind Handshake-
Statusinformation und zur Steuerung des Geräts. Control- Pakete, die nur die PID enthalten.
Transfers haben eine reservierte Bandbreite, die mindestens
10 % bzw. 20 % eines Frames bzw. Microframes beträgt. 2.5 Protokollarisches
Ein Interrupt-Transfer hat, entgegen seinem Namen, nichts 2.5.1 Busprotokoll
mit einem Interrupt bzw. Interrupt-Request im herkömm- Alle USB-Transfers werden vom Host-Controller initiiert.
lichen Sinne zu tun. Es handelt sich lediglich um einen Transaktionen zwischen Host und Gerät benötigen drei
sich kontinuierlich wiederholenden Transfer. Dieser wird Pakete (siehe Abbildung 5):
vom Host-Controller eingerichtet und ist unidirektional. Das
Gerät hat also keine Möglichkeit selbst den Bus in irgen-
1. Das Token-Paket wird vom Host-Controller gesendet
deiner Weise zu unterbrechen, wie es der Name suggerieren
und beinhaltet den Typ der Transaktion, die Richtung,
könnte.
die Adresse des beteiligten USB-Gerätes und die Num-
mer des Endpunktes.
Bulk-Transfers werden verwendet um größere Mengen an
Daten zu übertragen. Sie besitzen keine garantierte Latenz 2. Das Daten-Paket wird vom Host oder vom Gerät
oder Bandbreite. Deshalb werden sie ausgeführt, wenn noch gesendet und enthält die Daten.
Zeit im aktuellen Microframe vorhanden ist.
3. Das Handshake-Paket wird vom Empfänger (Host oder
Isochronous-Transfers können von FullSpeed- und Gerät) versendet und gibt an, ob die Transaktion er-
HighSpeed-Geräten durchgeführt werden und haben folgreich war.Host Gerät
Host Host
Pipes
ACK (6) (6) ACK Gerätetreiber IN- / OUT-Endpunkt
DATA (5) Default-Control-Pipe
(5) DATA
(4)
USB-Systemtreiber Endpunkt Null
IN-Token
(4) OUT-Token implementiert GET_DESCRIPTOR-
Request
b b b
(3) Device
ACK
(3) ACK
Configuration b b b
(2) DATA
DATA (2)
b b b
Interface
(1) OUT-Token (1) IN-Token phy. Bus
Host-Controller Bus Interface
Gerät Gerät
OUT-Transfer IN-Transfer Figure 6: Logischer Aufbau von USB-Host und
Gerät
Figure 5: Pakete eines IN-/OUT-Transfers mit zwei
Transaktionen (USB 2.0); Zusammenfassung der
2.5.4 Geräteklassen
Pakete im SuperSpeed-Protokoll (rot-gestrichelte
Geräteklassen können aus dem DEVICE- bzw.
Rahmen)
INTERFACE-Deskriptor bestimmt werden und dienen
zur Identifizierung des Gerätes. Häufig können auch un-
terschiedliche Geräte der selben Geräteklasse den gleichen
Das SuperSpeed-Protokoll weicht von dieser Vorgabe ab,
generische USB-Treiber verwenden. So wird eine zusätzliche
weil es aufeinanderfolgende Pakete des Hosts zusammen-
Treiberinstallation für ähnliche Geräte vermieden. Außer-
fasst. Für OUT-Transaktionen wird das Token in das
dem können auch Unterklassen und Protokollversionen
DATA-Paket integriert. Für IN-Transaktionen wird das To-
angegeben werden.
ken von einem Handshake-Paket ersetzt (siehe Abbildung
5).
2.6 Hubs
USB-Hubs dienen in der physikalischen Topologie als
2.5.2 Requests “Verteiler”. Sie besitzen einen sogenannten Upstreamport,
Um Geräte über die Control-Pipe anzusprechen bzw. zu mit dem sie an den bestehenden USB angeschlossen werden
konfigurieren, werden Requests verwendet. Sie enthalten fol- und mehrere Downstreamports, die Anschlussmöglichkeiten
gende Elemente: für weitere USB-Geräte bieten.
HighSpeed-Hubs müssen sogenannte Splittransaktionen aus-
• Request-Code: gibt die Art des Requests an führen können. Diese sind nötig, weil ein LowSpeed- oder
FullSpeed-Gerät nicht den restlichen Bus “ausbremsen” soll.
• wValue: Parameter für den Request Bei einer Splittransanktion verläuft die Kommunikation mit
einem solchen Geräten in HighSpeed und nur der letzte
• wIndex: (meistens) zur Angabe eines Endpunktes Hub spricht mit dem Gerät im geforderten LowSpeed- oder
FullSpeed-Modus.
• wLength: Länge der Daten, die bei der darauffolgen-
den Transaktion gesendet werden sollen Ein USB-3.0-Hub ist eine logische Kombination aus zwei
Hubs: einem USB-2.0-Hub und einem SuperSpeed-Hub.
Der USB-2.0-Hub ist mit den USB-2.0-Anschlüssen ver-
Je nach verwendetem Request-Typ kann sich die Be-
bunden, während der SuperSpeed-Hub die SuperSpeed-
deutung aber auch von dieser Definition unterscheiden.
Anschlüsse kontrolliert (siehe Abbildung 2). Konsequenter-
Einige wichtige Requests sind GET CONFIGURATION,
weise kann ein USB-3.0-Hub alle Adern des Upstreamports
GET DESCRIPTOR, GET INTERFACE, SET STATUS,
nutzen und gibt sich als zwei Geräte aus: ein SuperSpeed-
SET ADDRESS.
Hub am SuperSpeed-Bus und ein USB-2.0-Hub am USB-
2.0-Bus [3].
2.5.3 Deskriptoren
Deskriptoren beschreiben die Charakteristiken eines 2.7 USB-Treibersystem
Gerätes. Durch sie erhält der Host die benötigten In- Die für den USB-Host benötigten Treiber gliedern sich in
formationen, um den richtigen Treiber für das Gerät drei Ebenen:
auszuwählen. Der Aufbau eines Deskriptors erfolgt nach
einem festgelegten Schema, das sowohl verpflichtende als
auch optionale Felder definiert. • Treiber für den Host-Controller: Der Host-Controller-Treiber (HCD) bietet eine abstrakte Schnittstelle, Michael Rupp hat in seiner Arbeit [8] untersucht, wie
die unabhängig vom konkret verwendeten Typ des das bisher für den lokalen Kernel konzipierte und imple-
USB-Controllers ist. Verwendet werden der Univer- mentierte USB-System in den transaktionalen verteilten
sal Host Controller (UHC) oder der Open Host Con- Kernel integriert werden kann. Die folgenden Abschnitte
troller (OHC) im LowSpeed und FullSpeed-Modus, stellen eine Zusammenfassung der untersuchten Integra-
der Enhanced Host Controller (EHC) für HighSpeed- tionsmöglichkeiten dar.
Übertragungen und der Extensible Host Controller
(XHC) für den mit USB 3.0 eingeführten SuperSpeed- 3.2 Lokaler Ansatz
Modus. Beim lokalen Ansatz wird die bisherige Implementierung im
lokalen Kernel an den verteilten Kernel angebunden. Dazu
• Generischer USB-Treiber (USBD): Der USBD bietet werden die Schnittstellen zu den einzelnen Gerätetreiber als
Gerätetreibern die Möglichkeit Kommandos an Geräte Dummy-Klassen im verteilten Kernel angeboten. Die ein-
abzusetzen und Daten in und aus Pipes zu trans- fachste Möglichkeit zur Realisierung verwendet dann einen
ferieren. Er benutzt die HCDs. Task im verteilten Kernel, der kontinuierlich prüft (Polling),
ob neue Daten für eine Dummy-Klasse Daten vorliegen, oder
• Gerätetreiber (für USB-Geräte): Gerätetreiber im-
nicht.
plementieren gerätespezifische Funktionen und nutzen
dafür den USBD.
Allerdings ergibt sich eine Problematik, die bei den beiden
anderen Ansätzen auch auftritt: der Abbruch im verteilten
3. INTEGRATIONSMÖGLICHKEITEN Kernel. Sendet ein Task des verteilten Kernels mittels Mi-
DES USB-SYSTEMS IN RAINBOW crokernelinterface einen Schreibbefehl, so wird dieser auch
dann vom lokalen Kernel ausgeführt, wenn ein Abbruch im
3.1 Rainbow verteilten Kernel erfolgt. Nach dem Abbruch ist es für den
Das verteilte Betriebssystem Rainbow wird am Institut für verteilten Kernel außerdem nicht mehr ersichtlich, dass der
verteilte Systeme an der Universität Ulm entwickelt. Es ist Schreibvorgang stattfand. Als Lösung wird ein spezieller
ein 64-Bit-System, welches transaktionale Speicheroperatio- DMA-SmartBuffer zur Übergabe der Daten vom verteilten
nen auf einem gemeinsamen verteilten Speicher bietet. Als an den lokalen Kernel vorgeschlagen. Dabei werden die
Hardware werden mehrere 64-Bit Standard-PCs verwendet Befehle in den Speicher des lokalen Kernels geschrieben.
[7]. Der lokale Kernel darf sie jedoch erst ausführen, wenn
sichergestellt ist, dass der schreibende Task (des verteilten
Der Zugriff auf den verteilten Speicher erfolgt in Rainbow Kernels) nicht mehr abgebrochen werden kann bzw. abge-
nach dem ACID-Prinzip4 . Die Zugriffe werden mittels op- brochen wurde. Dies wird erreicht, indem ein zweiter Task
timistischer Synchronisation durchgeführt. Wird bei einem im verteilten Kernel überprüft, ob der erste Task abge-
Task ein Konflikt festgestellt, so wird er abgebrochen und brochen wurde, oder nicht.
es erfolgt eine Rückabwicklung seiner bisherigen Schreibzu-
griffe (Rollback). 3.3 Gemischter Ansatz
Der gemischte Ansatz beschreibt die fast willkürliche
Innerhalb von Rainbow werden zwei verschiedene Kernel
Aufteilung des USB-Treibers auf die beiden Kernel. Zusät-
ausgeführt. Der lokale Kernel dient zum Booten des Rechn-
zlich zur Problematik beim Austausch der Daten zwischen
ers und zur Initialisierung der Geräte, die für den verteilten
den Kerneln, nimmt hier auch die Anzahl der betroffenen
Betrieb benötigt werden. Als Beispiel kann hier die Netzw-
Schnittstellen zu. Um später dynamisch Treiber hinzufü-
erkkarte genannt werden. Anschließend wird der verteilte
gen zu können, bietet es sich an, die Gerätetreiber und den
Kernel gestartet.
USBD in den verteilten Kernel zu integrieren. Der hard-
warenahe EHC-Treiber wird dagegen im lokalen Kernel, der
Der verteilte Kernel liegt im verteilten Speicher und wird
nicht unterbrochen werden kann, angesiedelt. Die Inter-
verteilt ausgeführt. Da beide Kernel voneinander ge-
rupts können direkt vom EHC-Treiber verarbeitet werden
trennt sind, ist eine Kommunikation zwischen ihnen nur
und brauchen nicht in den verteilten Kernel weitergeleitet
eingeschränkt möglich. Dafür wird das Mikrokernelinterface
werden. Auch Dummy-Klassen sind im verteilten Kernel
verwendet, das es erlaubt, vom verteilten Kernel aus Funk-
nicht nötig. Die von der Abbruchproblematik betroffe-
tionen des lokalen Kernels aufzurufen. Zusätzlich kann der
nen Schnittstellen werden wie im lokalen Ansatz mit einem
lokale Speicher verwendet werden um Daten auszutauschen.
DMA-SmartBuffer versehen.
Im Gegensatz zum lokalen Kernel, der nur seinen eigenen
lokalen Speicher sieht, kann der verteilte Kernel auf beide
Speicherbereiche zugreifen. So ist es für ihn möglich Daten 3.4 Verteilter Ansatz
an eine fest definierte lokale Speicheradresse zu schreiben Beim verteilten Ansatz wird der lokale Kernel so klein
und einen Softwareinterrupt auszulösen. Der daraufhin wie möglich gehalten und alle wesentlichen Teile des USB-
ausgeführte lokalen Kernel interpretiert die Daten, führt Systems im verteilten Kernel implementiert. Ein Abbruch
entsprechende Funktionen aus und schreibt eventuelle Rück- ist deshalb nahezu im kompletten USB-System möglich.
gabewerte ebenfalls an eine definierte Speicherstelle [8]. Mit- Besonders die Datenstrukturen des EHC-Treibers, die sich
tlerweile existiert auch ein Interface in Gegenrichtung, um im lokalen Speicher befinden, müssen dagegen abgesichert
vom lokalen Kernel aus mit dem verteilten Kernel zu kom- werden.
munizieren.
Durch die Verlagerung des EHC-Treibers in den verteilten
4
ACID: atomicity, consistency, isolation und durability Kernel entsteht außerdem ein Problem mit den Interrupts.Sie müssen nun weitergeleitet und im verteilten Kernel be-
handelt werden. Im lokalen Kernel findet dafür eine Zwis-
chenpufferung des Statusregisters beim Auftreten des Inter-
rupts statt. Die Übergabe an den verteilten Kernel erfolgt
dann mittels des SmartBuffer-Prinzips.
Ein Vorteil dieses Ansatzes ist, dass der EHC-Treiber mit
dem USBD im gleichen Kernel integriert ist. Dadurch
gestaltet sich die Implementierung der dazwischenliegenden
Schnittstelle problemlos. Außerdem entspricht ein kleiner
lokaler Kernel dem bisherigen Design von Rainbow.
3.5 Schlussfolgerungen
Da besonders auf das Hinzufügen von USB-Treibern zur
Laufzeit Wert gelegt wird, scheidet der lokale Ansatz aus.
Weil die dynamische Generierung von Objekten nur im
verteilten Kernel möglich ist, dürfen sich die USB-Treiber
für eine solche Funktionalität nicht im lokalen Kernel
befinden.
Um den lokalen Kernel möglichst klein zu halten, wurde aus
der verbleibenden Auswahl der verteilte Ansatz vorgezogen.
4. REFERENCES
[1] Universal Serial Bus Specification. Compaq, Digital
Equipment Corporation, IBM PC Company, Intel,
Microsoft, NEC, Northern Telecom, rev 1.0, Januar
1996.
[2] Universal Serial Bus Specification. Compaq,
Hewlett-Packard, Intel, Lucent, Microsoft, NEC,
Philips, rev 2.0, April 2000.
[3] Universal Serial Bus 3.0 Specification. Hewlett-Packard
Company, Intel Corporation, Microsoft Corporation,
NEC Corporation, ST-NXP Wireless, Texas
Intruments, rev 1.0, November 2008.
[4] http://en.wikipedia.org/wiki/universal serial bus.
Wikipedia, Juni 2010.
[5] D. Anderson. Introduction to USB 3.0. MindShare,
Inc., August 2009.
[6] B. Benz. Pfeilschnell. c’t, 22 2008.
[7] N. Kaemmer, S. Gerhold, T. Baeuerle, and
P. Schulthess. Transactional distributed memory
management for cluster operating systems. In
Electronics and Microelectronics (MIPRO).
International Convention on Information and
Communication Technology, 2009.
[8] M. Rupp. Entwicklung eines transaktionalen Treibers
für einen USB Hostcontroller. Diplomarbeit,
Universität Ulm, Februar 2009.
[9] USB Implementers Forum. Introduction to USB
On-The-Go.Sie können auch lesen
