Einführende Betrachtung des USB und Möglichkeiten der Integration in das Rainbow-Betriebssystem

Transkript

1 Einführende Betrachtung des USB und Möglichkeiten der Integration in das Rainbow-Betriebssystem ABSTRACT Diese Ausarbeitung führt in die Funktionsweise und Hardware des Universal Serial Bus (USB) ein. Dabei werden die einzelnen Spezifikationen, die verwendete Hardware, die zugrundeliegende 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 Georg Gottleuber Institut für Verteilte Systeme Universität Ulm Albert-Einstein-Allee Ulm 1. EINFÜHRUNG Der Universal Serial Bus (USB) findet seit seiner Einführung in der ersten Version 1995 im Desktop-, Embedded- und Servermarkt eine weite Verbreitung. Die Stecker und Buchsen sind an nahezu all diesen en zu finden. Die gängigen Betriebssysteme Windows, Mac OS, Linux und BSD unterstützen die Verwendung von USB durch entsprechende Treiber. Das an der Universität Ulm entwickelte transaktionale verteilte Betriebssystem Rainbow verwendet PCs, die ebenfalls USB-Hardware enthalten. Für die transaktionale Unterstützung der USB-Treiber werden verschiedene Ansätze erläutert, die von Michael Rupp [8] erarbeitet wurden. 2. USB 2.1 Topologie Der USB verbindet USB-e mit dem USB-Host. Die physikalischen Verbindungen können in mehreren Ebenen sternförmig angeordnet werden (siehe Abbildung 1). Verzweigungen werden durch sogenannte Hubs realisiert. Wegen Zeitvorgaben können höchstens sieben Ebenen verwendet werden. Da die Anschlüsse des Hosts bereits als Root-Hub implementiert sind, können maximal Figure 1: Physikalische Bus-Topologie (Abbildung aus [2]) fünf herkömmliche Hubs untereinander verwendet werden. Verbundgeräte, die mehrere Funktionen anbieben (z.b.: Drucker und Scanner) können dann jedoch nicht auf der untersten Ebene benutzt werden, da sie zwei Ebenen benötigen. 2.2 Spezifikationen Die Version 1.0 der USB-Spezifikation erschien 1995 und damit im gleichen Jahr wie Apples IEEE 1394 Firewire- Standard. Ausgearbeitet von den Firmen Compaq, Digital Equipment Corporation, IBM PC Company, Intel, Microsoft, NEC und Northern Telecom sollte USB eine schnelle, bidirektionale, günstige, dynamisch an- und absteckbare, serielle Schnittstelle schaffen [1]. Als weitere Merkmale werden selbstidentifizierende Peripheriegeräte, automatische Treiberauswahl und Konfiguration, Expansion der PC-Anschlussmöglichkeiten auf bis zu 127 e, erweiterbare Architektur und einfach zu handhabende günstige 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 Dokument). 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 Geschwindigkeitsmodi interessant. Die Übertragung im LowSpeed-Modus er-

2 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 Bruttodatenrate. Als Verkabelung werden ungedrillte und ungeschirmte Kabel 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 und 2.4.4) neu ein. Mit der USB-Spezifikation in Version 2.0 wurde ein HighSpeed-Modus eingeführt, der eine Bruttoübertragunsrate von bis zu 480 Mbit/s ermöglicht. Dabei werden die bisherigen FullSpeed-Verbindungskabel verwendet. Der Funktionalität von USB 1.x 2 en bleibt unberührt. Außerdem können diese e ohne unnötigen Geschwindigkeitsverlust an USB-2.0-Hubs betrieben werden. Ebenfalls können USB-1.x-Hubs in die Topologie integriert werden. Unterhalb eines solchen Hubs ist dann jedoch keine HighSpeed-Übertragung möglich. Die Ende 2008 erschienene Version 3.0 der USB- Spezifikation beschreibt einen SuperSpeed-Modus, der bis zu 5 Gbit/s Daten transferiert. Dafür werden jeweils zum Senden und zum Empfangen ein neues Aderpaar verwendet (differenzielle Übertragung). Als Konsequenz daraus mussten neue Steckverbinder und entsprechende Kabel eingeführt werden. Die SuperSpeed-Transfers verwenden nur die neuen Aderpaare, während USB-2.0-Transfers nur über die bisherigen verlaufen. Die gleichzeitige Verwendung von USB-3.0- und USB-2.0-Adern bleibt allein Hubs vorbehalten (siehe Abschnitt 2.6). Die neuen Buchsen sind aber abwärtskompatibel zu USB-2.0-Kabeln und en. Neben dem bestehenden USB-2.0-System wurde so quasi eine parallele SuperSpeed-Infrastruktur mit eigenem Protokoll geschaffen. Dieses Protokoll unterscheidet sich jedoch nur in Einzelheiten, sodass die bisherigen hardwareunabhängigen Treiber mit wenigen Modifikationen weiter verwendet werden können. In einem USB-3.0-Bus bleiben durch die beschriebene Dual-Bus-Architektur USB-2.0-e uneingeschränkt benutzbar [3] (Abbildung 2). Außerdem werden folgende Neuerungen für den SuperSpeed-Modus genannt [5],[6]: Dual-Simplex-Unicast-Bus: Während USB 2.0 ein Half-Duplex-Broadcast-Bus zugrunde liegt, arbeitet SuperSpeed als Dual-Simplex-Unicast-Bus. Dadurch ist es möglich gleichzeitig IN- und OUT-Transaktionen durchzuführen. 1 In den späteren Spezifikationen wurden die Längenbeschränkungen wieder aufgehoben und nur noch die notwendigen elektrischen Eigenschaften und maximalen Signallaufzeiten vorgegeben. 2 Mit dieser Schreibweise werden USB 1.0 und USB 1.1 konforme e zusammengefasst. Figure 2: USB 3.0 Dual-Bus-Architektur (Abbildung aus [3]) Stromversorgung: SuperSpeed-e dürfen (bei unveränderter Versorgungsspannung von 5 V) nach einer erfolgreichen High-Power-Anfrage bis zu 900 ma Strom verbrauchen (USB 2.0 nur 500 ma). Ohne Anfrage dürfen 150 ma bezogen werden (USB 2.0 nur 100 ma). Idle-Pakete: Wie bisher führen die Verbindungen des USB kein extra Taktsignal. Alle angeschlossenen e halten den Takt, indem sie spezielle Synchronisationssignale auf den Datenleitungen nutzen. Um den Takt trotz der erhöhten Geschwindigkeit von USB 3.0 zu halten, werden kontinuierlich Pakete versendet. Wenn eine SuperSpeed-Verbindung keine regulären Pakete überträgt, werden Idle-Pakte übertragen. Um unnötigen Stromverbrauch zu vermeiden, wird ein weitgehendes Power-Management eingeführt. Senkung des Stromverbrauchs: Das neue Power- Management definiert neben dem Übertragungszustand ( Operational ) noch drei weitere Standby- und 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 e ebenfalls in einem Energiesparzustand sind. Kein Polling: Das bisher strikte Polling wird durch die Einführung einer neuen asynchronen Nachricht vermieden. So muss der Host nun beispielsweise nicht mehr ständig bei der USB-Tastatur nachfragen, ob neue Nutzereingaben vorhanden sind. Stattdessen frägt er einmal, worauf die Tatstatur mit NRDY ( Not Ready ) antwortet. Daraufhin entfallen weitere Anfragen, da die Tastatur, sobald sie neue Eingaben bekommt ein ERDY ( Endpoint Ready ) sendet. Nun frägt der Host mit der Gewissheit, dass neue Daten

3 vorhanden sind nach. Als Antwort erhält er vom die neuen Daten. Data-Bursts: Data-Bursts erlauben es dem Host oder bis zu 16 -Pakete zu senden, ohne auf eine Bestätigung ( ) zu warten. Dadurch wird der Protokoll-Overhead wesentlich reduziert. Scrambling: Um elektromagnetische Störungen durch sich wiederholende Datenmuster bei der Übertragung zu minimieren, werden die Daten mit einem pseudozufälligen Zahlenstrom mittels XOR vermengt (Methode wie bei PCIe 2.0). Host Typ A Mini-A Typ B Mini-B Abzüglich des Protokoll-Overheads kann der Anwender laut Spezifikation so eine Nettodatenraten von ca. 400 MB/s nutzen Micro-AB Micro-B Alle weiteren Ausführungen beziehen sich, wenn nicht explizit anders gekennzeichnet, auf die USB-2.0-Spezifikation. 2.3 Hardware 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 beschrieben. 3 Verbunden wurde der Host mit dem mittels einem Kabel welches einen A-Stecker auf einen B- Stecker führte. Da nur diese Sorte von Kabeln verfügbar war, konnte es nicht passieren, dass versehentlich zwei e oder zwei Hosts miteinander verbunden wurden. Wegen des großen Platzbedarfs der Buchsen bei zunehmend kleiner werdenden en, wurden Mini-A- und Mini-B- Buchsen eingeführt und Verbindungskabel mit A- auf B- Stecker beider Größen hergestellt. Für noch kleinere e wurden später Micro-B-Buchsen und entsprechende Kabel realisiert. Allerdings sollten nun e auch ohne einen PC untereinander USB- Verbindungen benutzen können. Als Beispiel kann hier eine direkte Verbindung der Digitalkamera mit einem Fotodrucker dienen. Diese Funktionalität wird USB On-The- Go (OTG) bezeichnet. Eines der beiden e übernimmt dann die Host-Rolle. Diese OTG-e wurden mit einer Micro-AB-Buchse ausgestattet, weil sie beide Rollen einnehmen können. Bei einer solchen Verbindung muss nur ein OTG beherrschen, welches zum Host wird [9]. Abbildung 3 zeigt die üblichen und standardisierten USB- Anschlüsse. Um besonders bei den Typ-A-Buchsen Verwechslungen zwischen USB 3.0 und den älteren Varianten auszuschließen, wird von der USB-3.0-Spezifikation eine Farbkodierung in blau vorgeschlagen. 2.4 Logischer Aufbau Frames und Micro-Frames USB verwendet bei der Einteilung der Bandbreite eine Zeiteinheit von 1 ms (USB 1.x) als sogenannten Frame bzw. 125 µs (USB 2.0) als Micro-Frame. Bestimmten Transfertypen kann so eine kontinuierliche Bandbreite und Latenz zugesichert werden. 3 Stecker und Buchsen mit der Bezeichnung A werden immer auf Hostseite verwendet. Die Bezeichnung B kennzeichnet immer die eseite. Typ A Micro-AB Typ B Micro-B Figure 3: USB-Anschlüsse: USB 1.x und 2.0 in grau, USB 3.0 in blau (USB 2.0 aus [4]) Endpunkte Jedem wird vom Host-Controller eine eindeutige Adresse zwischen 1 und 127 zugewiesen. Außerdem kann jedes unabhängig voneinander nutzbare Endpunkte anbieten. Endpunkte werden als IN-Endpunkte bezeichnet, wenn sie die Kommunikation zum ermöglichen. Als OUT-Endpunkte benennt man Endpunkte, die zur Kommunikation zum Host dienen. Minimal muss jedoch ein Endpunkt Null, der zur Konfiguration benötigt wird, unterstützt werden. Dieser IN-/OUT-Endpunkt bietet einen kombinierten Betrieb [8] Pipes Eine Pipe stellt die Verbindung zwischen deinem Endpunkt eines es und der Software des Hosts dar. Außerdem werden Pipes mit der Datenbandbreite assoziiert. Die meisten Pipes werden bei der Konfiguration eines USB-es angelegt. Es gibt zwei verschiedene Pipe-Typen. Stream-Pipes sind unidirektional und werden zum Datentransfer benutzt. Die Struktur, der transportierten Daten ist nicht spezifiziert. Stream-Pipes bieten Interrupt-, Bulkund Isochronous-Transfers. Message-Pipes sind im Gegensatz dazu bidirektional und übertragen spezifizierte Datenstrukturen. Sie werden für Control-Transfers genutzt und folgen einem speziellen Interaktionsschema. Zu erst wird vom Host ein Request (siehe Abschnitt 2.5.2) an das geschickt. Darauf folgt

4 Transfers 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 Zeitverzögerung folgt dann ein Statusbericht. Eine besondere Message-Pipe, die sogenannte Default-Control-Pipe, existiert immer, sobald ein angeschlossen ist. Sie gibt Zugriff auf die ekonfiguration, den Status und Kontrollinformation [2] Transfers Ein Transfer wird durchgeführt, wenn eine Software eine Funktion des USB-es nutzt, z.b. Daten kopiert. Eine Charakterisierung des Datenflusses wird dabei durch vier verschiedene Transfertypen vorgegeben: Control-Transfers müssen von jedem USB- unterstützt werden. Sie dienen der Konfiguration, dem Auslesen von Statusinformation und zur Steuerung des s. Control- Transfers haben eine reservierte Bandbreite, die mindestens 10 % bzw. 20 % eines Frames bzw. Microframes beträgt. Ein Interrupt-Transfer hat, entgegen seinem Namen, nichts mit einem Interrupt bzw. Interrupt-Request im herkömmlichen Sinne zu tun. Es handelt sich lediglich um einen sich kontinuierlich wiederholenden Transfer. Dieser wird vom Host-Controller eingerichtet und ist unidirektional. Das hat also keine Möglichkeit selbst den Bus in irgendeiner Weise zu unterbrechen, wie es der Name suggerieren könnte. Bulk-Transfers werden verwendet um größere Mengen an Daten zu übertragen. Sie besitzen keine garantierte Latenz oder Bandbreite. Deshalb werden sie ausgeführt, wenn noch Zeit im aktuellen Microframe vorhanden ist. Isochronous-Transfers können von FullSpeed- und HighSpeed-en durchgeführt werden und haben eine zugesicherte Bandbreite und Latenz. Sie besitzen keine Fehlerkorrektur und kein Handshake-Paket, da auftretende Fehler toleriert werden. Als Einsatzgebiete sind Audio- und Video-Streams angedacht Transaktionen Ein USB-Transfer besteht aus verschiedenen Transaktionen. Während Transfers über verschiedene (Micro-)Frames verteilt sein können, müssen USB-Transaktionen innerhalb eines (Micro-)Frames abgehandelt werden.[8] Pakete Die verschiedenen Pakete einer Transaktion setzen sich üblicherweise aus einer Paket-ID (PID), Daten und einem CRC zusammen. Hiervon ausgenommen sind Handshake- Pakete, die nur die PID enthalten. 2.5 Protokollarisches Busprotokoll Alle USB-Transfers werden vom Host-Controller initiiert. Transaktionen zwischen Host und benötigen drei Pakete (siehe Abbildung 5): 1. Das Token-Paket wird vom Host-Controller gesendet und beinhaltet den Typ der Transaktion, die Richtung, die Adresse des beteiligten USB-es und die Nummer des Endpunktes. 2. Das Daten-Paket wird vom Host oder vom gesendet und enthält die Daten. 3. Das Handshake-Paket wird vom Empfänger (Host oder ) versendet und gibt an, ob die Transaktion erfolgreich war.

5 Host Host Host Pipes (6) (6) etreiber IN- / OUT-Endpunkt (5) (4) OUT-Token (4) IN-Token (5) Default-Control-Pipe USB-Systemtreiber Endpunkt Null implementiert GET_DESCRIPTOR- Request (2) (1) OUT-Token (3) (3) (1) IN-Token (2) Host-Controller phy. Bus Device Configuration Interface Bus Interface OUT-Transfer IN-Transfer Figure 5: Pakete eines IN-/OUT-Transfers mit zwei Transaktionen (USB 2.0); Zusammenfassung der Pakete im SuperSpeed-Protokoll (rot-gestrichelte Rahmen) Das SuperSpeed-Protokoll weicht von dieser Vorgabe ab, weil es aufeinanderfolgende Pakete des Hosts zusammenfasst. Für OUT-Transaktionen wird das Token in das -Paket integriert. Für IN-Transaktionen wird das Token von einem Handshake-Paket ersetzt (siehe Abbildung 5) Requests Um e über die Control-Pipe anzusprechen bzw. zu konfigurieren, werden Requests verwendet. Sie enthalten folgende Elemente: Request-Code: gibt die Art des Requests an wvalue: Parameter für den Request windex: (meistens) zur Angabe eines Endpunktes wlength: Länge der Daten, die bei der darauffolgenden Transaktion gesendet werden sollen Je nach verwendetem Request-Typ kann sich die Bedeutung aber auch von dieser Definition unterscheiden. Einige wichtige Requests sind GET CONFIGURATION, GET DESCRIPTOR, GET INTERFACE, SET STATUS, SET ADDRESS Deskriptoren Deskriptoren beschreiben die Charakteristiken eines es. Durch sie erhält der Host die benötigten Informationen, um den richtigen Treiber für das auszuwählen. Der Aufbau eines Deskriptors erfolgt nach einem festgelegten Schema, das sowohl verpflichtende als auch optionale Felder definiert. Figure 6: Logischer Aufbau von USB-Host und eklassen eklassen können aus dem DEVICE- bzw. INTERFACE-Deskriptor bestimmt werden und dienen zur Identifizierung des es. Häufig können auch unterschiedliche e der selben eklasse den gleichen generische USB-Treiber verwenden. So wird eine zusätzliche Treiberinstallation für ähnliche e vermieden. Außerdem können auch Unterklassen und Protokollversionen angegeben werden. 2.6 Hubs USB-Hubs dienen in der physikalischen Topologie als Verteiler. Sie besitzen einen sogenannten Upstreamport, mit dem sie an den bestehenden USB angeschlossen werden und mehrere Downstreamports, die Anschlussmöglichkeiten für weitere USB-e bieten. HighSpeed-Hubs müssen sogenannte Splittransaktionen ausführen können. Diese sind nötig, weil ein LowSpeed- oder FullSpeed- nicht den restlichen Bus ausbremsen soll. Bei einer Splittransanktion verläuft die Kommunikation mit einem solchen en in HighSpeed und nur der letzte Hub spricht mit dem im geforderten LowSpeed- oder FullSpeed-Modus. 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 verbunden, während der SuperSpeed-Hub die SuperSpeed- Anschlüsse kontrolliert (siehe Abbildung 2). Konsequenterweise kann ein USB-3.0-Hub alle Adern des Upstreamports nutzen und gibt sich als zwei e aus: ein SuperSpeed- Hub am SuperSpeed-Bus und ein USB-2.0-Hub am USB- 2.0-Bus [3]. 2.7 USB-Treibersystem Die für den USB-Host benötigten Treiber gliedern sich in drei Ebenen: Treiber für den Host-Controller: Der Host-Controller-

6 Treiber (HCD) bietet eine abstrakte Schnittstelle, die unabhängig vom konkret verwendeten Typ des USB-Controllers ist. Verwendet werden der Universal Host Controller (UHC) oder der Open Host Controller (OHC) im LowSpeed und FullSpeed-Modus, der Enhanced Host Controller (EHC) für HighSpeed- Übertragungen und der Extensible Host Controller (XHC) für den mit USB 3.0 eingeführten SuperSpeed- Modus. Generischer USB-Treiber (USBD): Der USBD bietet etreibern die Möglichkeit Kommandos an e abzusetzen und Daten in und aus Pipes zu transferieren. Er benutzt die HCDs. etreiber (für USB-e): etreiber implementieren gerätespezifische Funktionen und nutzen dafür den USBD. 3. INTEGRATIONSMÖGLICHKEITEN DES USB-SYSTEMS IN RAINBOW 3.1 Rainbow Das verteilte Betriebssystem Rainbow wird am Institut für verteilte Systeme an der Universität Ulm entwickelt. Es ist ein 64-Bit-System, welches transaktionale Speicheroperationen auf einem gemeinsamen verteilten Speicher bietet. Als Hardware werden mehrere 64-Bit Standard-PCs verwendet [7]. Der Zugriff auf den verteilten Speicher erfolgt in Rainbow nach dem ACID-Prinzip 4. Die Zugriffe werden mittels optimistischer Synchronisation durchgeführt. Wird bei einem Task ein Konflikt festgestellt, so wird er abgebrochen und es erfolgt eine Rückabwicklung seiner bisherigen Schreibzugriffe (Rollback). Innerhalb von Rainbow werden zwei verschiedene Kernel ausgeführt. Der lokale Kernel dient zum Booten des Rechners und zur Initialisierung der e, die für den verteilten Betrieb benötigt werden. Als Beispiel kann hier die Netzwerkkarte genannt werden. Anschließend wird der verteilte Kernel gestartet. Der verteilte Kernel liegt im verteilten Speicher und wird verteilt ausgeführt. Da beide Kernel voneinander getrennt sind, ist eine Kommunikation zwischen ihnen nur eingeschränkt möglich. Dafür wird das Mikrokernelinterface verwendet, das es erlaubt, vom verteilten Kernel aus Funktionen des lokalen Kernels aufzurufen. Zusätzlich kann der lokale Speicher verwendet werden um Daten auszutauschen. 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 an eine fest definierte lokale Speicheradresse zu schreiben und einen Softwareinterrupt auszulösen. Der daraufhin ausgeführte lokalen Kernel interpretiert die Daten, führt entsprechende Funktionen aus und schreibt eventuelle Rückgabewerte ebenfalls an eine definierte Speicherstelle [8]. Mittlerweile existiert auch ein Interface in Gegenrichtung, um vom lokalen Kernel aus mit dem verteilten Kernel zu kommunizieren. 4 ACID: atomicity, consistency, isolation und durability Michael Rupp hat in seiner Arbeit [8] untersucht, wie das bisher für den lokalen Kernel konzipierte und implementierte USB-System in den transaktionalen verteilten Kernel integriert werden kann. Die folgenden Abschnitte stellen eine Zusammenfassung der untersuchten Integrationsmöglichkeiten dar. 3.2 Lokaler Ansatz Beim lokalen Ansatz wird die bisherige Implementierung im lokalen Kernel an den verteilten Kernel angebunden. Dazu werden die Schnittstellen zu den einzelnen etreiber als Dummy-Klassen im verteilten Kernel angeboten. Die einfachste Möglichkeit zur Realisierung verwendet dann einen Task im verteilten Kernel, der kontinuierlich prüft (Polling), ob neue Daten für eine Dummy-Klasse Daten vorliegen, oder nicht. Allerdings ergibt sich eine Problematik, die bei den beiden anderen Ansätzen auch auftritt: der Abbruch im verteilten Kernel. Sendet ein Task des verteilten Kernels mittels Microkernelinterface einen Schreibbefehl, so wird dieser auch dann vom lokalen Kernel ausgeführt, wenn ein Abbruch im verteilten Kernel erfolgt. Nach dem Abbruch ist es für den verteilten Kernel außerdem nicht mehr ersichtlich, dass der Schreibvorgang stattfand. Als Lösung wird ein spezieller DMA-SmartBuffer zur Übergabe der Daten vom verteilten an den lokalen Kernel vorgeschlagen. Dabei werden die Befehle in den Speicher des lokalen Kernels geschrieben. Der lokale Kernel darf sie jedoch erst ausführen, wenn sichergestellt ist, dass der schreibende Task (des verteilten Kernels) nicht mehr abgebrochen werden kann bzw. abgebrochen wurde. Dies wird erreicht, indem ein zweiter Task im verteilten Kernel überprüft, ob der erste Task abgebrochen wurde, oder nicht. 3.3 Gemischter Ansatz Der gemischte Ansatz beschreibt die fast willkürliche Aufteilung des USB-Treibers auf die beiden Kernel. Zusätzlich zur Problematik beim Austausch der Daten zwischen den Kerneln, nimmt hier auch die Anzahl der betroffenen Schnittstellen zu. Um später dynamisch Treiber hinzufügen zu können, bietet es sich an, die etreiber und den USBD in den verteilten Kernel zu integrieren. Der hardwarenahe EHC-Treiber wird dagegen im lokalen Kernel, der nicht unterbrochen werden kann, angesiedelt. Die Interrupts können direkt vom EHC-Treiber verarbeitet werden und brauchen nicht in den verteilten Kernel weitergeleitet werden. Auch Dummy-Klassen sind im verteilten Kernel nicht nötig. Die von der Abbruchproblematik betroffenen Schnittstellen werden wie im lokalen Ansatz mit einem DMA-SmartBuffer versehen. 3.4 Verteilter Ansatz Beim verteilten Ansatz wird der lokale Kernel so klein wie möglich gehalten und alle wesentlichen Teile des USB- Systems im verteilten Kernel implementiert. Ein Abbruch ist deshalb nahezu im kompletten USB-System möglich. Besonders die Datenstrukturen des EHC-Treibers, die sich im lokalen Speicher befinden, müssen dagegen abgesichert werden. Durch die Verlagerung des EHC-Treibers in den verteilten Kernel entsteht außerdem ein Problem mit den Interrupts.

7 Sie müssen nun weitergeleitet und im verteilten Kernel behandelt werden. Im lokalen Kernel findet dafür eine Zwischenpufferung des Statusregisters beim Auftreten des Interrupts 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 [2] Universal Serial Bus Specification. Compaq, Hewlett-Packard, Intel, Lucent, Microsoft, NEC, Philips, rev 2.0, April [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 [4] serial bus. Wikipedia, Juni [5] D. Anderson. Introduction to USB 3.0. MindShare, Inc., August [6] B. Benz. Pfeilschnell. c t, [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, [8] M. Rupp. Entwicklung eines transaktionalen Treibers für einen USB Hostcontroller. Diplomarbeit, Universität Ulm, Februar [9] USB Implementers Forum. Introduction to USB On-The-Go.