Fachhochschule Ingolstadt

Transkript

1 Fachhochschule Ingolstadt Fachbereich: Studiengang: Ingenieurwissenschaften Elektro- und Informationstechnik Thema: Entwurf und Programmierung eines WDM-Treibers zur Anbindung eines Datenloggers an eine USB-Schnittstelle Vor- und Zuname: Werner Glöckl ausgegeben am: abgegeben am: Erstprüfer: Prof. Dr. Bernhard Glavina Zweitprüfer: Prof. Dr. Johann Schweiger

2 Inhaltsverzeichnis Danksagung...V 1. Einleitung Kapitel Übersicht Motivation Voraussetzungen Begriffe und Konventionen Grundlagen Windows Entwicklungsgeschichte Der Aufbau von Windows Usermode Kernelmode Treiberarten Usermode Treiber Kernelmode Treiber Althergebrachte Treiber WDM Treiber Windows Driver Model (WDM)...22

3 4.1 Einführung Allgemeiner Aufbau I/O-System Bearbeitung von I/O-Anforderungen Plug&Play (PnP) Power-Management Codesynchronisation Treiber Objekt (Driver Object) Geräte Objekt (Device Object) I/O Request Packet (IRP) Allgemeiner Aufbau eines IRP IRP Struktur Universal Serial Bus (USB) Einführung USB Topologie Transferarten USB Treiber Schichten Schnittstelle des USB Bustreibers USBD USB Request Block (URB) Hardware USB Baustein Mikrocontroller Programmierung des USB Treibers Techniken der Treiberentwicklung Benennungskonventionen Betriebssystemfunktionen Softwareumgebung... 67

4 7.2.1 Windows 2000 DDK Microsoft Visual Studio Installation des Treibers Aufbau der INF Datei Hardwareassistent Debugging WinDbg KdPrint mit DebugView Ausgaben mit Hilfe vom Hyperterminal Blue Screen of Death (BSD) Beispieltreiber Haupteinstiegspunkte USB Deskriptor auslesen Daten an das USB Gerät senden Usermode Anwendung Ausblick Anhang Begleit-CD Abkürzungen Abbildungsverzeichnis Literatur und Links Hilfsmittel zur Erstellung der Diplomarbeit Erklärung...97

5 Danksagung Ich möchte die folgenden Zeilen dazu nutzen, den Personen zu danken die mich auf meinem Weg zum Ingenieur beleitet haben. Dies schließt alle Personen auf meinem gesamten Bildungsweg mit ein. Viele werden es nie explizit erfahren, dass Ihnen so von mir ein Dank für Ihre Unterstützung zugekommen ist. Speziell für meine Diplomarbeit gilt als erstes mein Dank Volker Weiß, Reinhold Sedlmeier, Carsten Seebeck, Professor Dr. Bernhard Glavina und Professor Dr. Johann Schweiger, die es mir überhaupt ermöglicht haben, dieses Diplomarbeitsthema bearbeiten zu dürfen. Mein weiterer Dank gilt an jenen, die mich während der Bearbeitung mit Ideen, handwerklichen Tätigkeiten, Verbesserungen und vielen mehr unterstützt haben. Last but not Least danke ich all meinen Freunden, Bekannten und vor allem meinen Eltern die meine oft unerträglichen Höhen und Tiefen, sowohl in der Zeit dieser Diplomarbeit, als auch während meines gesamten Studiums ertragen haben müssen und mir aber trotzdem immer unterstützend zur Seite gestanden sind. V

6 Kapitel 1: Einleitung 1. Einleitung 1.1 Kapitel Übersicht Das Ziel der Arbeit besteht darin, den Leser in die USB Treiberentwicklung unter Windows 2000 einzuführen. In 8 Kapiteln werden die einzelnen Bestandteile näher betrachtet, die zur Programmierung eines USB Treibers notwendig sind. - Kapitel 2: Grundlagen Windows 2000 In diesem Kapitel werden die Ziele bei der Entwicklung des Betriebssystems und der daraus resultierende Aufbau von Windows 2000 erläutert. Die Unterscheidung zwischen Usermode und Kernelmode spielt gerade bei der Treiber Programmierung eine sehr wichtige Rolle. - Kapitel 3: Treiberarten Windows 2000 bietet die Möglichkeit verschiedene Arten von Treibern zu implementieren. Dieses Kapitel gibt einen kurzen Überblick über die verschiedenen Treiberarten. Bei meinem Entwurf des Treibers war die Art des Treibers sehr entscheidend. In dieser Diplomarbeit wurde ein mittlerer WDM Treiber realisiert. - Kapitel 4: Windows Driver Model (WDM) Das Kapitel befasst sich mit dem großen Thema WDM. Es wird der grundlegende Aufbau und die neu hinzugekommen Möglichkeiten des Betriebssystems wie Plug&Play und Power-Management erklärt. Die bei WDM Treibern verwendeten Datenstrukturen werden ansatzweise näher beschrieben. Die Hauptaufgabe bei meiner Treiber Programmierung bestand darin, geeignete Dispatch Einstiegspunkte zu setzten, und danach die Dispatch Funktionen mit Hilfe der WDM Datenstrukturen und Makros zu implementieren. 6

7 Kapitel 1: Einleitung - Kapitel 5: Universal Serial Bus (USB) Das Kapitel soll dem Leser die Funktionsweise des USB erklären. Es werden unter anderem die verschiedenen Transferarten erklärt. In diesem Kapitel sind die verschiedenen USB Treiber Schichten und hierbei besonders der USBD sehr wichtig. Der USBD diente bei meiner Diplomarbeit als Schnittstelle zu meinem USB Gerät. Die Aufgabe bestand darin, Kommandos meines Treibers an den USBD weiter zu geben. - Kapitel 6: Hardware Dieses Kapitel soll dem Leser das USB Gerät näher bringen. Für meine Diplomarbeit wurde die USB Hardware bereit gestellt. Die Firmware des Mikrocontrollers konnte beliebig nach meinen Vorstellungen verändert werden. - Kapitel 7: Programmierung des USB Treibers Kapitel 7 steht im Zeichen wie ein Treiber implementiert wird. Die Einstellungen der Entwicklungsumgebung werden beschrieben, und wie man den Treiber mit Hilfe von DebugView debuggen kann. Gerade das debuggen nahm bei meiner Diplomarbeit sehr viel Zeit in Anspruch. - Kapitel 8: Beispieltreiber Mit Hilfe des bei meiner Diplomarbeit geschriebenen Beispieltreibers werden die vermittelten Grundlagen praktisch umgesetzt. - Kapitel 9: Usermode Anwendung Bei der Usermode Anwendung wird gezeigt, wie die Dispatch Funktionen vom Treibern verwendet werden. 1.2 Motivation Wenn man den Zeitschriften glauben darf, ist auf über 80 Prozent aller PCs ein Produkt von Microsoft installiert. In Stabilität, Sicherheit und Netzwerkfähigkeit ist Windows 2000 den Konkurrenten wie Windows 98 aus dem eigenen Haus weit überlegen. Windows 2000 ist 7

8 Kapitel 1: Einleitung eine direkte Weiterentwicklung von Windows NT 4.0. Zudem ist es zu vielen Anwendungen kompatibel, die ursprünglich für die kleineren Betriebssysteme wie MS-DOS und Windows 3.1 entwickelt wurden. Auch im Office-Bereich hat sich der Quasistandard von Microsoft durchgesetzt. Kaum eine Firma kommt heutzutage ohne Word und Excel aus. Den Alternativen zu Microsoft (Linux) haften immer noch die Vorurteile der schwierigen und umständlichen Bedienung an, obwohl gerade Linux immer mehr an Bedeutung gewinnt. Anwender und Firmen, die Wert auf eine stabile Umgebung legen, wechseln daher immer öfter im Falle einer Erneuerung der Soft- und Hardware bzw. bei einer Neuanschaffung zu Windows Als Repräsentant der Windows NT Betriebssystemlinie von Microsoft präsentiert sich Windows 2000 in vielerlei Hinsicht als umfassende Weiterentwicklung. Eine der wichtigsten architektonischen Neuerungen ist die Implementation des Windows Driver Model (WDM), das eine seit langem klaffende Lücke zwischen der Windows 98 Linie und der Windows NT Linie schließt. Der Treiberquellcode von Windows 98- und Windows 2000 Treibern ist kompatibel. Beim Wechsel zu Windows 2000 kommt es aber auch zu Schwierigkeiten. Wer auf Programme angewiesen ist, die direkt mit der Hardware kommunizieren müssen, steht vor dem Problem, dass dies unter Windows 2000 vom Betriebssystem unterbunden wird. Wenn der Hersteller des Programms keine angepasste Version für Windows 2000 zur Verfügung stellt, ist der Wechsel zum neuen Betriebssystem nicht möglich. Eine Reihe von Softwarefirmen stehen daher vor der Aufgabe, ihre Programme an die Gegebenheiten von Windows 2000 anzupassen. Auch die sich immer schneller entwickelnde Hardwareindustrie kann auf die Unterstützung von Windows 2000 nicht verzichten, ohne einen stetig wachsenden Markt zu verlieren. Mit dem Win32 Application Programming Interface (API) stellt Microsoft für den Anwendungsprogrammierer eine gut dokumentierte Schnittstelle zur Verfügung. In einer Vielzahl von Publikationen wird das API bis ins kleinste Detail beschrieben. Wer jedoch direkt auf die Hardware zugreifen will, muss für diese unter Windows 2000 spezielle 8

9 Kapitel 1: Einleitung Treiber entwickeln. Dafür benötigt man ein extra Entwicklungswerkzeug, das Windows 2000 Driver Development Kit (DDK). Leider ist für dieses Kit im Gegensatz zum Win32 API die Dokumentation sehr dürftig. Die komplexen Zusammenhänge werden schlecht und unverständlich beschrieben und die Beispiele sind so kompliziert, dass man sie auch mit einiger Erfahrung in der Entwicklung von Treibern nur schwer durchschaut. Auch die Literatur hält sich zu diesem Thema sehr zurück. In dieser Diplomarbeit sollen alle wesentlichen Grundlagen zur Treiberentwicklung vermittelt werden. Wichtige interne Abläufe und Strukturen von Windows 2000 sollen ebenso erläutert werden, wie die Werkzeuge, die zur Erstellung von Treibern benötigt werden. Außerdem wird mit einem Beispieltreiber und einer Anwendung, die theoretischen Grundlagen in die Praxis umgesetzt. 1.3 Voraussetzungen Aufgrund des komplexen Themas werden beim Leser gewisse Voraussetzungen erwartet. So sollte man mit den Grundlagen der Windows Programmierung mit Hilfe des Win32 API vertraut sein. Da die Beispielanwendungen mit C++ entwickelt wurden, sind Kenntnisse in dieser Programmiersprache ebenfalls von Vorteil. Als Entwicklungsplattform wird Windows 2000 mit Service Pack 1 angenommen. Als Entwicklungsumgebung wurde Microsoft Visual Studio v6.0 mit Driver Development Kit für Windows 2000 verwendet. 9

10 Kapitel 1: Einleitung 1.4 Begriffe und Konventionen In der Diplomarbeit werden üblicherweise die englischen Fachbegriffe nicht übersetzt, wenn dies das Verständnis des vorgebildeten Lesers beeinträchtigen würde. Häufig vorkommende Abkürzungen, wie WDM oder USB, werden zunächst im Text beschrieben und zusätzlich im Anhang noch einmal kurz erläutert. Stücke aus dem Quellcode oder Funktionsnamen werden kursiv dargestellt. 10

11 Kapitel 2: Grundlagen Windows Grundlagen Windows 2000 Dieses Kapitel soll die Entstehung und den grundlegenden Aufbau von Windows 2000 erläutern. Im Vordergrund stehen dabei der Aufbau von Windows 2000, da er für die Entwicklung von Treibern von großer Bedeutung ist. 2.1 Entwicklungsgeschichte 1980 entwickelten Microsoft und IBM ein Betriebssystem namens OS/2. Neben vielen Vorteilen hatte dieses Betriebssystem einen entscheidenden Nachteil. Es war in Assembler geschrieben. Als Mitte der 80er Jahre die Reduced Instruction Set Computer (RISC) Prozessoren zunehmend an Einfluss gewannen und sich auch die Complex Instruction Set Computer (CISC) Familie rapide weiterentwickelte, entschieden Microsoft und IBM, ein neues Betriebssystem für die 90er zu entwickeln - OS/2 NT (New Technologie). Microsoft verkündete 1988, dass mehrere ehemalige Digital Mitarbeiter eingestellt wurden, um eine neue Version von OS/2 zu entwickeln wurde aber Microsofts Windows 3.1 so ein großer Erfolg, dass Ende des Jahres die Entscheidung fiel, aus OS/2 NT nun Windows NT zu machen. Die Allianz zwischen Microsoft und IBM zerbrach aus diesem Grund ein halbes Jahr später. Im Jahr 1993 wurde mit einiger Verspätung die erste Version von Windows NT mit der Versionsnummer 3.1 veröffentlicht. Bei der Entwicklung des neuen Betriebssystems sollten folgende Entwicklungsziele besonders im Vordergrund stehen: Erweiterbarkeit: Es soll möglich sein, das System zu erweitern, bzw. neue Hardware zu unterstützen, ohne die existierende Codebasis zu beeinflussen. 11

12 Kapitel 2: Grundlagen Windows 2000 Portabilität: Das Betriebssystem soll sich einfach an möglichst viele Hardwareplattformen anpassen lassen. Zuverlässigkeit und Robustheit: Das System soll sich selbst vor internen und externen Fehlern schützen. Anwendungen sollen unabhängig voneinander funktionieren und dürfen die Stabilität des Betriebssystems nicht beeinflussen. Kompatibilität: Es sollen möglichst viele existierende Programme und Hardware unterstützt werden. Leistung: Trotz der anderen Entwicklungsziele soll das System auf jeder Hardwareplattform so schnell wie möglich arbeiten. Ziele sind natürlich noch keine Realität, und im Laufe der Zeit werden mitunter Kompromisse bei einem Ziel notwendig, um ein anderes überhaupt erreichen zu können. Windows NT ist ein Betriebsystem und als solches natürlich denselben Arten von Kompromissen unterworfen, wie sie in allen Systemen zu finden sind erblickte Windows NT 4.0 das Licht der Welt. Mit dieser Aktualisierung wurde Windows NT zu einem vollständigen 32-Bit-Betriebssystem und erhielt die mittlerweile populäre Oberfläche und das Look&Feel von der Windows 9x Familie. Windows NT 4.0 umfasste zudem viele fortschrittliche Funktionen für Unternehmensanwender. Vor allem das Netzwerkmanagement würde stark verbessert und ausgebaut. Wie der Name von Windows 2000 schon erahnen lässt, stellte Bill Gates im Jahre 2000 das neue Betriebssystem der Öffentlichkeit vor. Gegenüber Windows NT 4.0 wurde die Internetkompatibilität verbessert und die Unterstützung des mobilen Einsatzes auf Notebooks vorangetrieben. Dank dem vom Windows 98 bekannten Windows Driver Model, 12

13 Kapitel 2: Grundlagen Windows 2000 vereinfachte sich gegenüber Windows NT 4.0 die Hardware-Installation. Es wurden jetzt eine breite Masse an aktuellen Plug&Play Geräten unterstützt. 13

14 Kapitel 2: Grundlagen Windows Der Aufbau von Windows 2000 Der Aufbau von Windows 2000 lässt sich Grundsätzlich in zwei Schichten einteilen. Auf Benutzerebene ausgeführte Anwendungen laufen in einem speziellen Hardware-Modus, der allgemein auch als Usermode bezeichnet wird. Der Code kann in diesem Modus nur solche Operationen ausführen, die als harmlos klassifiziert sind. Er kann keine I/O-Instruktionen für Hardwarezugriffe ausführen. Falls eine im Usermode laufende Anwendung auf die Ausführung eines privilegierten Befehls angewiesen ist, muss sie dazu einen Dienst des Betriebsystemkerns in Anspruch nehmen. Systemcode hingegen läuft im Hardware-Modus oder Kernelmode, der die Ausführung sämtlicher Prozessorinstruktionen gestattet, insbesondere auch jegliche I/O-Zugriffe auf Hardware sowie den Zugriff auf den gesamten Arbeitsspeicher aller Anwendungen, soweit dieser nicht auf einen Datenträger ausgelagert ist. Alle modernen Prozessoren bieten heute in der einen oder anderen Form die Implementation eines privilegierten und mindestens eines weniger privilegierten Betriebsmodus an, so dass Kernelmode Code in der privilegierten Umgebung und Usermode Code in der weniger privilegierten Umgebung ausgeführt werden können. Abbildung 2.1: Aufbau von Windows

15 Kapitel 2: Grundlagen Windows Usermode Die beiden Betriebsmoden lassen sich noch feiner in einzelne Bereiche einteilen. Anwendungen: Eine Anwendung im Usermode steht von der Abstraktionsebene gesehen ganz oben. Eine Anwendung soll dem Benutzer bestimmte Dienste des Systems bereit stellen. Als Schnittstelle zu den darunter liegenden Subsystemen wurden eine Fülle von APIs definiert. Jedes Subsystem hat seine eigenen APIs. Unter Windows 2000 sind Win32, Virtual DOS Machine (VDM), Windows On Windows (WOW), POSIX und OS/2 als Subsystem implementiert. Win32: Das Win32 Subsystem ist die gewöhnliche API von Windows Alle anderen Umgebungen führen sich in ihrer Arbeitweise auf dieses Subsystem zurück. Alle neuen Windows Anwendungen erwarten das Win32 Subsystem als Umgebung. Virtual DOS Machine (VDM): Das Subsystem der Virtual DOS Machine implementiert eine auf 16 Bit Code zugeschnittene MS-DOS Umgebung für althergebrachte DOS Anwendungen. Trotz aller Kompatibilitätsversprechen, die Microsoft verlauten ließ, funktionieren viele DOS Anwendungen unter Windows 2000 nicht oder zumindest nicht korrekt. Das liegt im Wesentlichen an dem von Microsoft auf Sicherheit bedachten Ansatz, der den Zugriff auf Geräte und andere Systemressourcen nur emuliert. Auf jegliche Versuche, diese Ressourcen direkt anzusprechen, reagiert das Betriebssystem mit Interventionen, die zwar zu sicheren Ergebnissen führen, nicht unbedingt aber zu den erwarteten. Windows On Windows (WOW): Das Subsystem Windows On Windows implementiert eine Win16 Umgebung für alte, noch im 16 Bit Code vorliegende Windows Anwendung, wie sie einst für Windows 3.x geschrieben wurden. 15

16 Kapitel 2: Grundlagen Windows 2000 POSIX: Das POSIX Subsystem ist eine spezielle API für Anwendungen, die im Unix Stil gehalten sind. Es so theoretisch möglich Unix Anwendungen auf dem Windows 2000 Betriebssystem laufen zu lassen. OS/2: Das OS/2 Subsystem erzeugt eine Ausführungsumgebung für 16 Bit OS/2 Anwendungen. Es steht allerdings nur für die Intel Derivate zur Verfügung. Das System Service Interface (SSI) ist die Schnittstelle zwischen Usermode und Kernelmode. Ohne auf die detaillierte Betrachtungsweise einzugehen stellt das (SSI) den Bezug von den Subsystemen und den ausführenden Diensten her Kernelmode Die ausführenden Dienste stellen sozusagen den Einstiegspunkt in den Kernelmode dar. Hier werden grundlegende Ein- und Ausgabeprozesse erledigt. Die ausführenden Dienste lassen sich in sieben Bereiche unterteilen: Grafikschnittstelle: Die Grafikschnittstelle oder auf Englisch das Graphical Device Interface (GDI) ist unter anderem der Fenstermanager. Hier werden für Programme Fenster erzeugt und verwaltet. Die Platzierung im Kernel und damit treibernah sorgt unter anderem für die hohe Performance der Oberfläche. Sicherheitsmonitor: Der Sicherheitsmonitor dient der Kontrolle und Steuerung der internen Sicherheit. Sowohl im Kernelmode als auch im Usermode werden Dienste zur Prüfung der Sicherheit zur Verfügung gestellt. Die Komponente selbst arbeitet im Kernel und führt beispielsweise den Anmeldeprozess aus, der für den Benutzer sichtbare Teil wird dagegen im Usermode ausgeführt. 16

17 Kapitel 2: Grundlagen Windows 2000 Objektmanager: Nahezu alle Betriebssystemdienste werden inzwischen mit einem Objekt modelliert. Objekte sind im Windows-Kern Abbildungen für Ressourcen. Das Betriebssystem verwaltet diese Objekte, das heißt, sie werden auf Anforderung erzeugt, ein Handle (Zeiger) darauf erstellt und nach der Benutzung gelöscht. Prozessmanager: Der Prozessmanager verwaltet Prozesse und Threads. Auch dies erfolgt mit Objekten, die folgerichtig Prozess- und Thread Objekte genannt werden. Jedes Programm, das startet, muss mindestens ein Prozess Objekt verwenden. Viele Prozesse werden im Windows Task-Manager angezeigt, einige können aber auch unsichtbar ablaufen. Speichermanager: Unter Windows 2000 umfasst der Adressraum 4GB, wobei aber für Usermode Anwendungen nur die unteren 2GB zur verfügen stehen. Der Speichermanager teilt Anwendungen Speicher zu und überwacht dessen Verwendung. Falls der physikalische Hauptspeicher nicht ausreicht, wird Speicher in der Auslagerungsdatei angefordert, sogenannter virtueller Speicher. Der Speichermanager heißt deshalb auch Virtual Memory Manager (VMM). Prozesskommunikation: Die Kommunikation zwischen Prozessen und Anwendungen übernimmt die Prozesskommunikation, ausgeführt durch Local Procedure Call (LPC). Dies ist das Gegenstück zum Remote Procedure Call (RPC) und dient der Vermittlung zwischen externen Programmen und intern ablaufenden Prozessen. I/O-Manager: Der I/O-Manager stellt alle Ein- und Ausgabevorgänge zur Verfügung. Treibern, die darunter liegen, wird eine einheitliche Schnittstelle zur Verfügung gestellt. Der I/O-Manager leitet die Usermode Prozesse in Form von I/O Request Packets (IRP) weiter. Ein IRP repräsentiert einen komplexen Auftrag, den der I/O-Manager für gewöhnlich selbst zusammenstellt und einem Treiber zur Bearbeitung vorsetzt. Aufgabe eines Geräte Treibers 17

18 Kapitel 2: Grundlagen Windows 2000 ist es somit, an ihn gerichtete IRPs abzuarbeiten. I/O-Manager und Treiber sind eng miteinander verbunden. Mikrokernel: Die nächste Ebene im Kernelmode ist der Mikrokernel. Der Mikrokernel ist ein Kernbestandteil des Betriebssystems. Damit soll gesichert werden, dass nur ein möglichst kleiner Teil des gesamten Systems im geschützten Modus abläuft. Dies dient der Stabilität. Je mehr Teile in den geschützten Bereich überführt werden, desto unsicherer wird das Gesamtsystem. Mit dem Mikrokernel werden nun elementare Prozesse geschützt abgewickelt, die große Masse der Vorgänge läuft aber im Usermode ab. Der Mikrokernel steuert den Prozessor. Hier werden die von Anwendungen angeforderten Prozessorleistungen aufgeteilt oder so gesteuert, dass die Verteilung korrekt verläuft (Multitasking). Auch die Einhaltung von Prioritäten wird hier entschieden. Der Mikrokernel stellt weiterhin Schnittstellen und bestimmte interne Objekte zur Verfügung, die beispielsweise für die Interruptbehandlung verantwortlich sind. Der Mikrokernel selbst ist für Anwender unsichtbar. Er wird nur im Fehlerfall dem sogenannten Blue Screen of Death (BSD) aktiv. Treiber: Auf die gleiche hierarchische Ebene wie der Mikrokernel sind die unterschiedlichen Treiber zu setzten. Treiber erlauben es auf die jeweilige Peripherie zuzugreifen. Dadurch das der Treiber eng mit der Hardware verankert ist, greifen die Schutzmechanismen des Betriebssystems nicht. Ein schlecht programmierter Treiber kann somit das ganze System zum Absturz bringen. Das in Windows 2000 und Windows 98 neu eingeführte Windows Driver Model (WDM) soll eine einheitliche Struktur in der Treiberprogrammierung bringen. Das WDM wird im nächsten Kapitel detailliert beschrieben. Hardware Abstraction Layer (HAL): Die HAL ist die unterste Schicht von Windows. Hier wird direkt auf den verwendeten Prozessor und bestimmte Besonderheiten der Hardware bezug genommen. Es ist allerdings möglich, das Treiber den HAL umgehen und direkt auf Hardware zugreifen. 18

19 Kapitel 3: Treiberarten 3. Treiberarten Auf höchster Abstraktionsebene unterscheidet man bei Windows 2000 zwischen Usermode und Kernelmode Treibern. Dieses Kapitel soll nur die prinzipielle Klassifizierung der Treiber verdeutlichen. In späteren Kapiteln wird außerdem auf die USB spezifischen Treiber Schichten eingegangen. Abbildung 3.1: Treiberklassifizierung für Windows Usermode Treiber Wie der Name bereits verrät, ist ein Usermode Treiber nichts anderes als ein auf Systemebene angesiedelter Code, der im Usermode ausgeführt wird. Ein Usermode Treiber wird oft auch als virtueller Treiber bezeichnet. Nachdem der Usermode von Windows 2000 keinen direkten Zugriff auf Hardware gestattet, ist ein virtueller Treiber immer auf einen realen Treiber angewiesen, der im Kernelmode läuft. Auf Usermode Treiber wird in dieser Arbeit nicht weiter eingegangen. 19

20 Kapitel 3: Treiberarten 3.2 Kernelmode Treiber Kernelmode Treiber sind reale Treiber, die es gestattet auf reale Hardware zuzugreifen. Betrachtet man die Sache eine Ebene tiefer, so lassen sich Kernelmode Treiber weiter in althergebrachte NT Treiber und Windows Driver Model (WDM) konforme Treiber einteilen Althergebrachte Treiber Unter althergebrachte Treiber versteht man die ursprünglichen NT Treiber. Ihr großer Nachteil ist, dass sie ausschließlich unter dem Betriebssystem Windows NT 4.0 funktionieren. Wie bei den Usermode Treiber wird auch hier nicht detaillierter darauf eingegangen WDM Treiber WDM Treiber sind Plug&Play (PnP) tauglich. Darüber hinaus kommen sie mit Energieverwaltung, Autokonfiguration und Hot-Plugging zurecht. Ein korrekt geschriebener WDM Treiber lässt sich sowohl für Windows 2000 als auch Windows 98 einsetzen. Eine weitere Ebene tiefer lassen sich NT Treiber sowie WDM Treiber gleichermaßen in drei Kategorien unterteilen, nämlich in höhere, mittlere und niedere Treiber. Wie es die Bezeichnungen bereits vermuten lassen, bauen höhere Treiber auf mittleren oder niederen Treibern auf. Während mittlere Treiber allein auf niederen Treibern aufbauen. Höhere Treiber: Höhere Treiber bieten sich nur dann an, wenn die untergelegte reale Hardware bereits von einem oder mehreren niederen Treibern bedient wird und nur eine abstraktere Sicht für Clients geschaffen werden soll. 20

21 Kapitel 3: Treiberarten Mittlere Treiber: Zu den mittleren Treibern gehören die sogenannten Klassen -und Filtertreiber. Klassentreiben beruhen darauf, Code innerhalb des Treibermodells mehrfach zu verwenden. Filtertreiber fangen an bestimmte Treiber gerichtete Anforderungen ab, um sie dem Adressaten erforderlichenfalls in abgewandelter Form zuzustellen. Niedere Treiber: Niedere Treiber sind Hardware nahe Treiber. Dazu zählen vor allem die Bustreiber. Solche Treiber interagieren mit der HAL von Windows 2000 oder auch direkt mit der Hardware. 21

22 Kapitel 4: Windows Driver Model (WDM) 4. Windows Driver Model (WDM) Das Windows Driver Model kann durch vier grundlegende Neuerungen gegenüber den bisher existierenden Architekturen charakterisiert werden: Klassentreiber: Die komplexe Aufgabe, Erstellen von Gerätetreibern für Hardware, basierend auf Standards wie USB oder IEEE 1394, wird durch das Klassentreiber Konzept erleichtert. Standardisiertes I/O-Modell: Die Zusammenstellung von Kernel Funktionen, Schnittstellen und Konventionen, welche aus dem I/O Modell von Windows NT abgeleitet werden, ermöglicht Binärkompatibilität der Gerätetreiber für Windows 98 und Windows Plug&Play: Zur Unterstützung von Plug&Play Funktionen werden neue Mechanismen bereitgestellt, die es ermöglichen, Veränderungen in der Systemkonfiguration an Gerätetreiber zu übermitteln. Power-Management: Den neuen Initiativen zur intelligenten Verwaltung von Energieressourcen in Computersystemen wird durch Einführung von Power-Management Funktionen Rechnung getragen. 4.1 Einführung Für das Verständnis der Vorgehensweise beim Erstellen von WDM Gerätereibern müssen einige Besonderheiten der Treiberprogrammierung berücksichtigt werden. Der Programmcode von Gerätetreibern repräsentiert, genau wie der Quellcode einer normalen Anwendung, ein ausführbares Programm. Jedoch gibt es keine Hauptfunktion, und damit ist 22

23 Kapitel 4: Windows Driver Model (WDM) auch keine lineare Ablaufstruktur vorhanden. Gerätetreiber arbeiten ereignisgesteuert, das heißt das Auftreten bestimmter Ereignisse veranlasst das Betriebssystem, bestimmte Funktionen des Treibers aufzurufen. Aufgabe des Treibers ist es, für diese Aufrufe entsprechende Behandlungsroutinen (Dispatch Routinen) zur Verfügung zu stellen. Zu beachten ist dabei, dass solche Routinen im Kontext verschiedener Systemprozesse aufgerufen werden und damit im Prinzip gleichzeitig ausgeführt werden können. Somit kann eine Datenstruktur des Treibers an mehreren Stellen quasi gleichzeitig manipuliert werden. Für solche Fälle müssen Vorkehrungen getroffen werden, welche jederzeit die Konsistenz der Daten garantieren. 4.2 Allgemeiner Aufbau WDM definiert, wie schon die existierenden Windows NT Betriebsysteme, ein objektorientiertes Treibermodell. Kernstück dieser Architektur ist der bereits vorgestellte I/O-Manager, durch den die Kommunikation sowohl zwischen Anwendung und Gerättreiber als auch der Informationsaustausch zwischen den verschiedenen Treibern koordiniert wird. Hierfür besitzt jeder Gerätetreiber ein direktes Interface zum I/O-System. Die zu einem I/O-Vorgang gehörenden Parameter werden innerhalb einer definierten Paketstruktur, als I/O Request Packet (IRP) bezeichnet, gespeichert und transportiert. Die Struktur des IRP wird später noch detaillierter erklärt. Für den Datenaustausch zwischen Anwenderprogrammen und Gerätereibern bestehen zwei grundlegende Möglichkeiten. Da Geräte des WDM Konzepts wie virtuelle Dateien behandelt werden, können die Daten unter Nutzung der Funktionen für den Dateizugriff (ReadFile(), WriteFile()) ausgetauscht werden. Zur Realisierung der Übergabe von Konfigurations- und Steuerbefehlen ist zusätzlich ein anderer Weg definiert. Mit dem Aufruf der Systemfunktion (DeviceIoControl()) wird ein spezieller Parameter an den Treiber übermittelt, der diesen veranlasst, bestimmte Funktionen auszuführen. 23

24 Kapitel 4: Windows Driver Model (WDM) Innerhalb der Kernel Umgebung erfolgt die Kommunikation grundsätzlich unter Nutzung der IRP, welche durch den Aufruf von Systemfunktionen von Treiber zu Treiber weitergegeben werden. 4.3 I/O-System Das I/O-Modell des WDM Konzepts bildet die grundlegende Basis für die Koordination des Zusammenspiels der Systemkomponenten und Anwendungen. Die zentrale Komponente dieses Modells ist der I/O-Manager. Dort läuft die gesamte Kommunikation zwischen Anwendungen (Usermode) und Gerätetreibern (Kernelmode) sowie zwischen den Treibern zusammen. Die Gerätetreiber sind direkt in das I/O-System eingebettet und besitzen eine direkte Schnittstelle zum I/O-Manager, welche auf zwei Objekten basieren. Diese Objekte sind das Treiber Objekt und das Geräte Objekt und werden später noch näher erklärt. Die Abbildung 4.1 soll das Zusammenspiel zwischen den zwei Objekten veranschaulichen: 24

25 Kapitel 4: Windows Driver Model (WDM) Abbildung 4.1: Objektmodell des I/O-Managers Der Zugriff des I/O-Manager auf die Funktionen des Treiber erfolgt über Dispatch Einstiegspunkte, welche durch das Treiber Objekt bereitgestellt werden. Die I/O-Funktionen des Treibers werden über die Dispatch Einstiegspunkte aufgerufen. Die Bekanntgabe der Einstiegspunkte innerhalb des Treiber Objekts erfolgt durch den Treiber selbst innerhalb der Funktion DriverEntry(). Diese Funktion muss in jedem Treiber implementiert sein. Nach dem Laden des Treibers wird DriverEntry() durch den I/O-Manager automatisch aufgerufen. Die einzelnen logischen Schichten der I/O-Verarbeitung sind auf übereinandergeschichtete Treiber aufgeteilt, welche während der Abarbeitung, beginnend bei der obersten Schicht, nacheinander durchlaufen werden. Der I/O-Manager definiert ein paketorientiertes asynchrones Kommunikationsmodell. Alle Parameter eines I/O-Vorgangs werden in einem IRP zusammengefasst. Für jede am jeweiligen Vorgang beteiligte Treiberschicht existiert 25

26 Kapitel 4: Windows Driver Model (WDM) innerhalb eines IRP ein Speicherplatz für die zugehörigen Daten. Dieser wird als I/O-Stack bezeichnet. Wichtige weitere Elemente eines IRP sind die Beschreibung des Datenbuffers für den Datenaustausch, ein I/O-Stauts Block für den Austausch von Statusinformationen des jeweiligen I/O-Vorgangs sowie ein Zeiger auf die aktuelle Position im I/O-Stack. Diese I/O-Stack Position enthält spezielle Informationen des I/O-Vorgangs für das jeweilige aktive Treibermodul. Im einzelnen sind dies der Funktionscode des Vorgangs mit den dazugehörigen Parametern, der Zeiger auf das Geräte Objekt sowie optional ein Zeiger auf eine Routine, die zur späteren Weiterverarbeitung des IRP benutzt werden kann. Abbildung 4.2: I/O Verarbeitung 26

27 Kapitel 4: Windows Driver Model (WDM) 4.4 Bearbeitung von I/O-Anforderungen Für das Bearbeiten von I/O- Anforderungen sind zwei Konzepte definiert. Abbildung 4.3: Synchrone und asynchrone I/O-Vorgänge Der I/O-Manager ruft zur Bearbeitung eines IRP als Bestandteil einer I/O-Anforderung die entsprechende Dispatch Routine des jeweiligen Treibers über den vereinbarten Einstiegspunkt auf. Der Treiber wertet den Funktionscode und zugehörigen Parameter aus und entscheidet dann, wie das IRP bearbeitet werden muss. Entweder erfolgt die Bearbeitung durch den aktuellen Treiber, oder das IRP wird an die nächste Schicht weitergegeben. Wird das IRP vom aktuellen Treiber bearbeitet, kann das unmittelbar oder verzögert erfolgen. 27

28 Kapitel 4: Windows Driver Model (WDM) Bei der unmittelbaren Bearbeitung werden die Eingabeparameter verarbeitet und als Ergebnis die Ausgabeparameter gesetzt. Nach dem Setzten des Staus der Operation wird die Anforderung abgeschlossen und der Status an den I/O-Manager zurückgegeben. Die verzögerte Bearbeitung eines IRP beginnt mit dem Verarbeiten von Eingabeparametern. Das IRP wird in einer internen Liste gespeichert, weitere Aktionen werden initiiert, und ein spezieller Statuscode wird zurückgegeben. Der Vorgang wird zu einem späteren Zeitpunkt, in der Regel durch einen Interrupt, abgeschlossen. Bei der Weiterleitung eines IRP erfolgt nach dem Verarbeiten der Eingabeparameter die Initialisierung der nächsten I/O-Stack Position. Optional kann eine Routine vereinbart werden, die zur späteren Signalisierung der abgeschlossenen Bearbeitung des IRP durch die nächste Treiberschicht dient. Diese Routine wird als Completion Routine bezeichnet. Mit IoCallDriver() wird das IRP an den nächsten Treiber weitergegeben. Ist die Bearbeitung des IRP durch den darunter liegenden Treiber abgeschlossen, wird durch den I/O-Manager eine eventuell vereinbarte Completion Routine aufgerufen. Das signalisiert dem höherliegendem Treiber, dass die Bearbeitung des IRP abgeschlossen ist, und ermöglicht eine eventuell notwendige zusätzliche Bearbeitung des I/O-Vorgangs. Der eigentliche Zweck eines I/O-Vorgang ist der Transport von Daten. Die transportierten Daten werden in bestimmten Speicherblöcken (Puffer) gehalten, welche von der Anwendung bereitgestellt werden. Für die Behandlung dieser Blöcke durch den I/O-Manager bestehen drei verschiedene Möglichkeiten: Buffered I/O-Processing (BIO): Bei dieser Methode erfolgt der Austausch von Daten zwischen Anwendung und Treiber immer unter Nutzung von Kernel Speicher. Dieser wird vom I/O-Manager allokiert. Der Abgleich von Systempuffer und Anwendungspuffer während des I/O-Vorgangs erfolgt durch das Kopieren der Daten zwischen den Puffern im Kontext des Usermode Threads. 28

29 Kapitel 4: Windows Driver Model (WDM) Direct I/O-Processing (DIO): Bei dieser Art der I/O-Verarbeitung erfolgt der Datenaustausch ausschließlich unter Verwendung des Anwendungspuffers. Der I/O-Manager sperrt dazu temporär die Auslagerung des Pufferspeichers und generiert eine Memory Description List (MDL) für den Puffer. Der Treiber oder die Hardware greift über diese MDL direkt auf den Anwendungsspeicher zu. I/O-Processing nach der Methode Neither: Im Gegensatz zum Direct I/O-Processing ist in diesem Fall der I/O-Manager nicht an der Pufferbearbeitung beteiligt. Der Gerätetreiber ist selbst für Zugriffssynchronisation und Adressverarbeitung verantwortlich. 4.5 Plug&Play (PnP) Mit der Einführung des WDM Konzepts werden die erstmals unter Windows 95 vorhandenen Plug&Play Funktionen erweitert. Die neu definierten Plug&Play Konzepte ermöglichen das Ändern der Systemkonfiguration im laufenden Betrieb. Es besteht hierbei keine Notwendigkeit der Interaktion mit dem Nutzer. Eine optimale Verteilung der Ressourcen wird jederzeit gewährleistet. Plug&Play wird innerhalb des Betriebssystems durch folgende Mechanismen repräsentiert: - Automatische und dynamische Erkennung der vorhanden Hardwarekomponente - Automatische Bereitstellung der benötigten Ressourcen der jeweiligen Hardwarekomponente - Automatisches Laden der benötigten Gerätetreiber - Bereitstellung einer Schnittstelle zur Kommunikation zwischen Gerätetreiber und Plug&Play System - Bereitstellung von Mechanismen zum Übermitteln von Hardware Änderungen an Anwendungen im Usermode Die Realisierung der Plug&Play Funktionen ist in zwei Kategorien aufgeteilt. Das Laden des Gerätetreibers für neu hinzugefügte Geräte und die Konfiguration dieser Geräte werden 29

30 Kapitel 4: Windows Driver Model (WDM) getrennt behandelt. Das Anschließen einer neuen Hardwarekomponente bewirkt das Laden des zugehörigen Gerätetreibers und den Aufruf der DriverEntry() Funktion dieses Treibers durch den I/O-Manager. Damit wird unter anderem der Einstiegspunkt AddDevice() dem Betriebssystem bekannt gegeben. Dieser Schritt entfällt, wenn der entsprechende Treiber bereits zu einem früheren Zeitpunkt durch Hinzufügen eines zugehörigen Gerätes, geladen wurde. Aufgabe der Funktion AddDevice() ist das Erzeugen und die Initialisierung eines Geräte Objekts für das neue Gerät (IoCreateDevice()) und das Einfügen dieses Objekts an die entsprechende Stelle im I/O-Subsystem (IoAttachDeviceToDeviceStack()) Initialisierung und Neukonfiguration der Geräte werden innerhalb der Funktion DispatchPnP() ausgeführt. Beim Aufruf dieser Funktion werden zusätzliche Parameter übergeben, mit dem der jeweils auszuführende Konfigurationsschritt festgelegt wird. 4.6 Power-Management Durch die Einführung von Mechanismen zur intelligenten Verwaltung von Energieressourcen trät das WDM Konzept zur Erhöhung des Komfort und der Effizienz im Rahmen der Nutzung von Computersystemen bei. Die grundlegenden Aspekte des Power-Managements werden innerhalb der OnNow Initiative von Microsoft behandelt. Hauptziele dieser Initiative sind die Reduzierung des Energieverbrauchs im laufendem Betrieb von PC Systemen durch das teilweise bzw. vollständige Abschalten von nicht benutzten Peripheriekomponenten. Eine Unterscheidung erfolgt durch die getrennte Betrachtung von Gesamtsystem und Peripheriekomponente. 30

31 Kapitel 4: Windows Driver Model (WDM) Die möglichen Zustände des Gesamtsystems werden von der Advanced Configuration and Power Interface (ACPI) Spezifikation abgeleitet und wie folgt definiert: S0 Prozessor vollständig in Betrieb, Peripherie nach Bedarf S1 Prozessortakt abgeschaltet S2 Prozessor Stromversorgung abgeschaltet, RAM Refresh vollständig S3 Prozessor Stromversorgung abgeschaltet, RAM Refresh reduziert S4 Gesamtes System abgeschaltet, Systemspeicher auf Festplatte gesichert S5 Gesamtes System abgeschaltet Für an einem Computer angeschlossene Geräte werden vier verschiedene Energiezustände definiert. Diese sind für jedes Gerät unabhängig vom Zustand des Gesamtsystems. Die vier Gerätezustände sind: D0 Gerät voll betriebsbereit D1 Low Power Mode, abhängig von Geräteklasse, Zustand der Hardware gesichert D2 Low Power Mode, abhängig von Geräteklasse, Zustand der Hardware verloren D3 Stromversorgung abgeschaltet, Zustand der Hardware verloren Die Verwaltung der Energieressourcen ist unter WDM in drei verschiedene Komponenten aufgeteilt. Für jede Geräteklasse bzw. jedes Subsystem innerhalb eines Rechners existiert eine dedizierte Komponente, welche die Managementfunktionen übernimmt. In den meisten Fällen ist dies ein Gerätetreiber, welcher innerhalb der Treiberstruktur an höchster Stelle angesiedelt ist (Klassentreiber). Diese Zuordnung resultiert aus der Tatsache, dass dieser Komponente alle Informationen zur Verfügung stehen, welche zur Verwaltung der Energieressourcen benötigt werden. Von dieser Steuerzentrale werden einheitliche Managementbefehle an den Gerätetreiber gesendet, welcher für das entsprechende Gerät zuständig ist. Es ist die Aufgabe des Treibers, diese universellen Kommandos in verständliche Befehle für das Gerät umzusetzen und den Verlust der Gerätekonfigurationen beim Übergang zwischen Energiezuständen zu verhindern. Bustreiber liegen unterhalb der Klassentreiber und Gerätetreiber und können optional ebenfalls Power-Management Kommandos an die Geräte versenden. In diesem Abschnitt wird nur auf Aspekte des Power-Managements in bezug auf Gerätetreiber eingegangen. Für alle Module, die aktiv an 31

32 Kapitel 4: Windows Driver Model (WDM) der Verwaltung von Energieressourcen teilnehmen, existiert eine einheitliche Schnittstelle zur Power-Management Komponente des Betriebssystems. Die Implementierung dieser Schnittstelle basiert auf der Nutzung von IRP. Die Power-Management Komponente von WDM sendet zur Realisierung einer Managementfunktion ein IRP mit dem Funktionscode IRP_MJ_POWER und noch einen Zusatzcode. Die Behandlungsfunktion für den Funktionscode muss drei grundlegende Aufgaben erfüllen. Die Bereitschaft zur Annahme eines solchen IRP muss durch den Funktionsaufruf (IoStartNextPowerIrp()) signalisiert werden. Zusätzlich zur Bearbeitung durch den angesprochenen Treiber muss jedes Power Management IRP unter Nutzung der Funktion PoCallDriver() an die nächst tiefere Treiberschicht weitergegeben werden. Alle gerätespezifischen Aktionen zur Bearbeitung der aktuellen Anforderung sind ebenfalls Aufgabe der Behandlungsroutine. 4.7 Codesynchronisation Alle Threads eines Programms unter Windows 2000 nutzen den gleichen Adressraum. Dies bietet den Vorteil, dass alle Threads eines Prozesses auf den gleichen Speicher zugreifen und so ihre Daten einfach austauschen können. Da der Zeitpunkt zum Umschalten zwischen den einzelnen Threads vom Prozess weder bestimmt noch beeinflusst werden kann, kann auch keine Konsistenz von Datenstrukturen vorausgesetzt werden. Es besteht die Möglichkeit, dass ein Thread während der Manipulation von Daten durch das System unterbrochen wird, um einen anderen Thread die Möglichkeit zu geben, auf die gleiche Datenstruktur zuzugreifen. Dies kann zu unvorhersehbaren Effekten führen. Speziell für Gerätetreiber ist deshalb als ein weiterer Aspekt zu beachten, dass verschiedene Gerätetreiber im Kontext mehrerer Threads gleichzeitig ausgeführt werden können. Die grundlegende Aufgabe der Multithread Programmierung besteht deshalb darin, Zugriffe auf Daten, welche von verschiedenen Threads gemeinsam genutzt werden, zu erkennen und richtig aufeinander abzustimmen. 32

33 Kapitel 4: Windows Driver Model (WDM) Routinen, welche gemeinsame Datenobjekte Manipulieren, werden als kritische Abschnitte bezeichnet und im Programmcode als solche gekennzeichnet. Die Ausführung solcher Abschnitte wird während der Laufzeit serialisiert. Der primäre Thread eines Prozesses initialisiert mit InitializeCriticalSection() eine globale Variable. Ein Thread kann beim Eintritt in einen kritischen Abschnitt mit EnterCriticalSection() andere Threads daran hindern, den Abschnitt ebenfalls auszuführen. Das System lässt die weitere Abarbeitung dieser Threads erst dann zu, wenn der Thread mit LeaveCriticalSection() den Abschnitt wieder freigibt. Kritische Abschnitte eignen sich nur dann für die Synchronisation des Datenzugriffs, wenn ausschließlich Threads eines Prozesses beteiligt sind und der wechselseitige Ausschluss zur Erfüllung der Aufgabe ausreichend ist. Das Win32 API definiert weitere Synchronisationsmechanismen, welche auch über Prozessgrenzen hinaus nutzbar sind. Dazu werden verschiedene Objekte mit unterschiedlicher Bedeutung bereitgestellt. Analog zum kritischen Abschnitt ist es möglich, Threads verschiedener Prozesse wechselseitig auszuschließen. Die hierfür verwendeten Objekte werden als Mutex (Mutual Exclusion) bezeichnet. Soll einer festgelegten Anzahl von Threads der Eintritt in einen bestimmten Programmabschnitt erlaubt werden, werden Semaphore zur Synchronisation benutzt. Ein Semaphor entspricht einem Mutex Objekt, welches um Mechanismen zum qualifizierten Ausschließen erweitert ist. Zur gegenseitigen Benachrichtigung von beliebig vielen Threads sind Event Objekte definiert. Ein Event wird zum Beispiel verwendet, wenn die Ausführung einer unbestimmten Anzahl von Threads vom Ereignis eines weiteren Threads abhängig ist. Die bei den jeweiligen Mechanismen verwendeten Objekte werden über vordefinierte Funktionen (CreateMutex(), CreateSemaphore(), CreateEvent()) generiert und durch einen textuellen Bezeichner, welcher allen beteiligten Prozessen bekannt sein muss, eindeutig identifiziert. Diese Objekte werden beim Auftreten des jeweiligen Ereignisses in den signalisierten Zustand versetzt. Die Synchronisation erfolgt durch den Aufruf einer einheitlichen Funktion (WaitForSingleObject(), WaitForMultipleObject()) für alle Objekttypen unter Angabe des bestimmten Bezeichners, wodurch auf den signalisierten Zustand des Objekts gewartet wird. 33

34 Kapitel 4: Windows Driver Model (WDM) Die bisher beschriebenen Mechanismen mit Ausnahme von kritischen Abschnitten stehen sowohl für Anwendungen als auch für Gerätetreiber im Kernelmode zur Verfügung. Darüber hinaus besteht im Kernelmode eine weitere Möglichkeit der Synchronisation über Spinlocks. Ein Spinlock stellt einen Synchronisationsmechanismus auf niedriger Ebene dar. Wenn durch einen Thread ein Spinlock angefordert wird (KeAcquireSpinLock()) wird er auf eine höhere Prioritätsebene angehoben. Allen anderen Threads des Systems ist der Zugriff auf die geschützten Datenstrukturen verboten, bis der Spinlock mit (KeReleaseSpinLock()) aufgehoben wird. Durch ihre spezifischen Eigenschaften sind Spinlocks auch zu Synchronisation über mehrere Prozessoren in der Lage. Bei der Verwendung von mehreren Synchronisationsobjekten innerhalb eines Programmabschnitts besteht die Gefahr von Deadlocks. Ein Deadlock entsteht, wenn sich verschiedene Threads durch die Anforderung des Synchronisationsobjekts gegenseitig blockieren. Um das zu vermeiden, sollte eine Hierarchie für die Anforderung von Synchronisationsobjekten definiert und konsequent eingehalten werden. Abbildung 4.4: Dispatcher Objekte 34

35 Kapitel 4: Windows Driver Model (WDM) 4.8 Treiber Objekt (Driver Object) Jedes Treiber Objekt repräsentiert ein Abbild eines geladenen Kernelmode Treibers und enthält alle Einsprungadressen des Treibers. Wenn ein Treiber geladen wird, erzeugt der I/O-Manager ein neues Treiber Objekt und ruft die Initialisierungsroutine DriverEntry() auf. Dort werden alle weiteren Einsprungadressen in das Objekt eingetragen. Sollte der Treiber sich nicht initialisieren können, wird das Treiber Objekt wieder gelöscht. Bei einer I/O-Anfrage benutzt der I/O-Manager das Objekt, um die richtige Dispatch Routine zu finden und aufzurufen. Abbildung 4.5: Treiber Objekt Das Treiber Objekt ist nicht vollständig dokumentiert, die Deklaration findet man aber in der Datei ntddk.h. DeviceObject: Zeigt auf ein oder mehrere Geräte Objekte, die vom Treiber erstellt wurden. Dieser Wert wird automatisch aktualisiert, wenn die Funktion IoCreateDevice() erfolgreich aufgerufen wurde. In der Unload() Routine werden dieser Wert und der Wert NextDevice 35

36 Kapitel 4: Windows Driver Model (WDM) von dem Geräte Objekt benutzt, um die Funktion IoDeleteDevice() für alle vom Treiber erzeugten Geräte Objekte aufzurufen. HardwareDatabase: Zeigt auf die Hardware Konfigurationsinformationen in der Registry. FastIoDispatch: Zeigt auf eine Struktur, die die Einsprungadressen des Treibers für Fast I/O enthält. DriverInit: Zeigt auf den Eintrittspunkt der DriverEntry() Routine und wird vom I/O-Manager initialisiert. DriverStartIo: Zeigt auf die Einsprungadresse der StartIo() Routine und wird von der DriverEntry() Routine initialisiert. Hat der Treiber keine StartIo() Routine, ist der Wert NULL. DriverUnload: Lässt sich der Treiber entladen, wird der Eintrittspunkt der Unload() Routine während der Initialisierung des Treibers von der DriverEntry() Routine hier abgelegt, ansonsten ist der Wert NULL. MajorFunction[]: Ist ein Feld mit einem und mehreren Eintrittspunkten von Dispatch Routinen des Treibers. Hier muss jeder Treiber mindestens einen Eintrittspunkt für IRP_MJ_XXX Funktionen, die er behandelt, festlegen. Es können so viele Eintrittspunkte festgelegt werden, wie IRP_MJ_XXX Codes behandelt werden. 36

37 Kapitel 4: Windows Driver Model (WDM) 4.9 Geräte Objekt (Device Object) Für jedes virtuelle, logische und physische Gerät im System gibt es ein Geräte Objekt, das Informationen über die Eigenschaften und den Status des Gerätes enthält. Die DriverEntry() Routine erzeugt für jedes Gerät, das der Treiber kontrolliert, ein Geräte Objekt mit Hilfe der Funktion IoCreateDevice(). Über die Variable NextDevice kann der Treiber dann nacheinander die verschiedenen Geräte abfragen. Die Treiberfunktionen können einen Teil des Geräte Objektes, die Geräteerweiterung, zum Speichern von Daten und Statusinformationen verwenden. Dabei wird die Struktur der Erweiterung vom Treiber selbst festgelegt. Die Unload() Routine des Treibers ist für das Entfernen der Objekte zuständig. Wenn mehrere Geräteobjekte erstellt wurden, muss der Treiber über NextDevice alle Objekte abfragen und löschen. 37

38 Kapitel 4: Windows Driver Model (WDM) Abbildung 4.6: Geräte Objekt Auch das Geräte Objekt ist nicht vollständig dokumentiert. Die komplette Deklaration ist wiederum in der Datei ntddk.h zu finden. DriverObject: Zeigt auf das zugehörige Treiber Objekt des Gerätes. 38

39 Kapitel 4: Windows Driver Model (WDM) NextDevice: Zeigt auf das nächste Geräte Objekt, wenn der Treiber mehrere Geräte verwaltet. Der I/O-Manager aktualisiert die Liste nach jedem erfolgreichen Aufruf der Funktion IoCreateDevice(). CurrentIrp: Zeigt auf das gegenwärtige IRP, wenn der Treiber gerade ein IRP verarbeitet. Ansonsten ist der Wert NULL. Flags: Nachdem das Geräte Objekt erzeugt wurde, setzt der Treiber diesen Wert auf Flags or BufferAccess wobei BufferAccess entweder DO_BUFFERED_IO oder DO_DIRECT_IO ist. Höhere Treiber führen Flags or LowerLevelDriverFlags aus. Characteristics: Wird auf einen der folgenden Werte gesetzt, wenn ein Treiber für Wechseldatenträger die Funktion IoCreateDevice() mit einem der entsprechenden Werte aufruft: FILE_REMOVABLE_MEDIA FILE_READ_ONLY_DEVICE FILE_FLOPPY_DISKETTE FILE_WRITE_ONCE_MEDIA DeviceExtension: Zeigt auf die Geräteerweiterung. Die Struktur und der Inhalt der Geräteerweiterung wird vom Treiber festgelegt. Die Größe der Struktur muss der Funktion IoCreateDevice() als Parameter übergeben werden. Die Geräteerweiterung stellt einen guten Mechanismus bereit, um Parameter zu speichern. DeviceType: Wird beim Aufruf der Funktion IoCreateDevice() auf den Wert des Parameters DeviceType gesetzt und legt den Typ des Gerätes fest. Wenn keine der Systemkonstanten FILE_DEVICE_XXX zutreffend sind, können eigene Werte im Bereich von bis definiert werden. Der Bereich von 0 bis ist von Microsoft reserviert. 39

40 Kapitel 4: Windows Driver Model (WDM) StackSize: Gibt die minimale Anzahl der StackLocations in einem IRP an, das dem Treiber übergeben wird. Die Funktion IoCreateDevice() setzt diesen Wert auf 1. Der I/O-Manager aktualisiert den Wert automatisch, wenn übergeordnete Treiber die Funktion IoAttachDevice() oder IoAttachDeviceToDeviceStack() aufrufen. Höher liegende Treiber, die sich selbst mit IoGetDevicePointer() über andere Treiber legen, müssen StackSize in ihrem eigenen Treiber Objekt explizit um eins erhöhen. AlignmentRequirement: Jeder Treiber setzt diesen Wert auf den benötigten Abgleich des Treibers. Höher liegende Treiber benutzen den Wert des zugrundeliegenden Treibers I/O Request Packet (IRP) Allgemeiner Aufbau eines IRP Ein IRP besteht aus einem festen Teil, dem IRP Header, und einem oder mehreren Parameterblöcken, sogenannten I/O Stack Locations. Der Header enthält unter anderem Daten über die Art und Größe der Anfrage, Statusinformationen und einen Zeiger auf einen Puffer, der zum Datenaustausch zwischen Treiber und Benutzeranwendung verwendet wird. Der Parameterblock enthält den Funktionscode der Anfrage und funktionsspezifische Parameter IRP Struktur Auch hier sind wiederum nicht alle Teile der IRP Struktur dokumentiert, allerdings kann man wieder in der Datei ntddk.h die vollständige Deklaration finden. 40

41 Kapitel 4: Windows Driver Model (WDM) Abbildung 4.7: IRP Struktur 41

42 Kapitel 4: Windows Driver Model (WDM) MdlAdress: Zeigt auf eine Speicherbeschreibungsliste Memory Descriptor List (MDL) für den Benutzerpuffer, wenn der Treiber im Direct I/O-Modus arbeitet und eine IRP_MJ_READ oder IRP_MJ_WRITE Aktion durchgeführt werden soll. Flags: Dieses Feld darf nur gelesen werden und kann folgende Zustände annehmen: IRP_NOCACHE IRP_PAGING_IO IRP_MOUNT_COMPLETION IRP_SYNCHRONOUS_API IRP_ASSOCIATED_IRP IRP_BUFFERED_IO IRP_DEALLOCATE_BUFFER IRP_INPUT_OPERATION IRP_SYNCHRONOUS_PAGING_IO IRP_CREATE_OPERATION IRP_READ_OPERATION IRP_WRITE_OPERATION IRP_CLOSE_OPERATION IRP_DEFER_IO_COMPLETION AssociatedIrp.MasterIrp: Zeigt auf das Master IRP, das von einem Treiber in der höchsten Ebene durch einen Aufruf von IoMakeAssociatedIrp() erzeugt wurde. AssociatedIrp.SystemBuffer: Zeigt auf einen Systemspeicherbereich für eine der folgenden Aktionen: - Transferanfrage für einen Treiber, der im Buffered I/O-Modus läuft - eine IRP_MJ_DEVICE_CONTROL Anfrage - eine IRP_MJ_INTERNAL_DEVICE_CONTROL Anfrage, deren I/O Control Code mit dem Wert METHOD_BUFFERED definiert ist. In jedem der Fälle werden Daten von bzw. auf diesen Speicherbereich übertragen. 42

43 Kapitel 4: Windows Driver Model (WDM) IoStatus: Ist der I/O-Statusblock, in den vor Aufruf der Funktion IoCompleteRequest() Statusinformationen gespeichert werden. RequestorMode: Gibt den Modus an, aus dem die Anfrage gestartet wurde, und hat entweder den Wert Usermode oder Kernelmode Cancel: Hat diese Variable den Wert TRUE, wurde oder wird die Anfrage abgebrochen. CancelIrql: Gibt den Interrupt Request Level (IRQL) des Treibers an, wenn IoAcquireCancelSpinLock() aufgerufen wird. CancelRoutine: Gibt die Adresse einer Cancel Routine an, wenn die Anfrage abgebrochen werden soll. Ist der Wert NULL, kann die Anfrage nicht abgebrochen werden. UserBuffer: Gibt die Adresse eines Ausgabepuffers an, wenn der Major Funktionscode den Wert IRP_MJ_INTERNAL_DEVICE_CONTROL und der I/O Control Code den Wert METHOD_NEITHER hat. Tail.Overlay.DeviceQueueEntry: Wenn IRPs in der Gerätewarteschlange stehen, verbindet dieser Wert die IRPs in der Warteschlange. Der Wert ist nur gültig, wenn das IRP gerade vom Treiber verarbeitet wird. Tail.Overlay.DriverContext: Wenn keine IRPs in der Warteschlange stehen, kann der Treiber hier bis zu vier Zeiger ablegen. Auf das Feld kann nur zugegriffen werden, wenn das IRP dem Treiber selbst gehört. 43

44 Kapitel 4: Windows Driver Model (WDM) Tail.Overlay.Thread: Zeigt auf den Thread Control Block des Aufrufers. Tail.Overlay.ListEntry: Wenn der Treiber eine eigene Warteschlange für IRPs verwaltet, wird dieser Wert benutzt um die IRPs miteinander zu verbinden. 44

45 Kapitel 5: Universal Serial Bus (USB) 5. Universal Serial Bus (USB) In diesem Kapitel wird der Universal Serial Bus (USB) näher betrachtet. In dieser Arbeit wird nur auf den USB 1.1 Standard eingegangen, weil der Treiber und das USB Gerät auf diesem Standard aufbauen. Der neue USB 2.0 Standard ermöglicht Transferraten von 480 MBit/s. Diese neue Schnittstelle ist zur Zeit allerdings nur in den aller neuesten Rechnern bzw. Notebooks anzutreffen. 5.1 Einführung Der USB ist eine schnelle und flexible externe Schnittstelle, die an heutigen Computern serienmäßig zu finden ist. Die Vorteile gegenüber anderen Schnittstellen sind: Universelle Schnittstelle: Der USB ist so vielseitig, dass er für viele Arten von Peripheriegeräten genutzt werden kann. Der USB 1.1 hat sich somit als Standardschnittstelle etabliert. Kabellänge: Die maximale Kabellänge ist auf 5 Meter begrenzt was aber für die meisten USB Geräte ausreichen dürfte. Leichter Anschluss: USB definiert einen einheitlichen Steckverbinder mit 4 Pins. 2 Pins sind für die serielle Datenübertragung und 2 Pins sind für die Bereitstellung der Betriebsspannung (+5V) und der Masse am USB Gerät. Stromversorgung: Peripheriegeräte können direkt über das Buskabel versorgt werden. Der maximal verfügbare Strom richtet sich nach dem versorgtem Hub. Hubs mit einer eigener Stromversorgung, wie 45

46 Kapitel 5: Universal Serial Bus (USB) zum Beispiel der Root Hub im PC, können pro Port maximal 500 ma bereitstellen. Hubs, welche selbst über das Buskabel versorgt werden, liefern pro Port maximal 100 ma. Automatische Konfiguration: Das Anstecken eines Peripheriegerätes am Bus wird durch den USB automatisch erkannt, und Windows 2000 konfiguriert das Gerät selbstständig, ohne Mitwirkung des Nutzers, für die sofortige Benutzung. Dies ist auch im laufenden Betrieb des Computers und der Anwendung möglich. Während des dynamischen Auf- und Abbaus der Verbindung wird kein Neustart erforderlich und wird oft als Hot Plug&Play bezeichnet. Ressourcen schonend: USB Geräte haben keine durch den Anwender wählbaren Einstellungen wie etwa Port Adressen und Interrupt Request Leitungen (IRQ). Es werden nur durch die USB Schnittstelle selbst, einige Ressourcen des Computers belegt, jedoch nicht für jedes angeschlossene Gerät. Viele Geräte anschließbar: An einen USB Hub sind maximal 127 physikalische USB Geräte anschließbar. Auch wenn man berücksichtigt, dass die unvermeidlichen Mehrfachverteiler oder auch Hubs genannt mitgezählt werden müssen. Ausreichende Geschwindigkeit: Der USB unterstützt zwei Geschwindigkeitsklassen: 1,5 MBit/s als Low Speed bezeichnet und 12 MBit/s als Full Speed bezeichnet. Die geringere Geschwindigkeit dient der Realisierung von preissensitiven Peripheriekomponenten, wie Tastatur, Maus usw., wodurch geringere Anforderungen an die Kabel gestellt werden können. 46

47 Kapitel 5: Universal Serial Bus (USB) 5.2 USB Topologie USB hat als Topologie ein kaskadierte Sternstruktur mit einem Host im Ursprung. Zur Bereitstellung von mehreren Anschlüssen dienen Hubs. Abbildung 5.1: USB Topologie Host: Sämtliche Transaktionen auf dem USB werden durch den Host gesteuert. Der Host ist in der Regel im PCI Chipsatz des PCs vorhanden und enthält einen integrierten Root Hub, der meistens zwei Ports bereits stellt. Der Host übernimmt die Verwaltung der Bandbreite und des Power-Managements für den gesamten Bus. Der zeitlich Ablauf aller Transaktionen wird durch die Host Software gesteuert. An den Bus neu angesteckte Geräte werden durch den Host enumeriert und damit dem System zur Verfügung gestellt. Vom Bus entfernte 47

48 Kapitel 5: Universal Serial Bus (USB) Geräte werden durch den Host beim System abgemeldet. Zur zeitlichen Synchronisation aller Geräte am Bus dient ein Frame. Jede Millisekunde sendet der Host ein Frame. Hub: Der Einsatz von Hubs ermöglicht den Anschluss von mehreren Geräten an ein bestehenden Port. Jeder Hub besitzt ein Upstream Port, das in Richtung Host zeigt, und mehrere Downstream Ports in Richtung der Endgeräte oder weiterer Hubs. Vom Host gesendete Daten werden durch einen Hub an alle seine aktiven Downstream Ports weitergeleitet. In der entgegengesetzten Richtung werden die Daten nur zum Upstream Port durchgeschaltet. Eine wesentliche Aufgabe der Hubs ist das Power-Management für angeschlossene Geräte. Hubs können über den Bus mit Strom gespeist werden oder eine eigene Stromversorgung besitzen. Hubs sind weiterhin für das Erkennen eines Connect (Anstecken eines Gerätes an einen Downstream Port) oder eines Disconnet (Abziehen eines Gerätes) verantwortlich. Endgeräte: Nach einem Power On Reset besitzt ein Endgerät die Defaultadresse 0. Erst im Verlauf der Enumeration wird dem Gerät eine eigene Adresse durch den Host zugewiesen. Endgeräte können zusammen mit einem Hub in einem Gerät untergebracht werden. Ein bekanntes Beispiel hierfür ist die USB Tastatur mit integriertem USB Hub. Durch die gute Erreichbarkeit der Anschlüsse ist die Erweiterung des USB für Nutzer sehr leicht möglich. Die Stromversorgung kann über das USB Kabel (Bus Powered) oder durch ein eigenes Netzteil erfolgen (Self Powered). Solange ein Endgerät noch nicht komplett konfiguriert ist, darf sie den Bus mit maximal 100 ma belasten. Nach dem Aktivieren ihrer Konfiguration darf die Stromaufnahme bis zu 500 ma betragen. 5.3 Transferarten Physikalisch besteht die Verbindung zu einem USB Gerät lediglich aus den Datenleitungen D+ und D-. Der USB unterstützt jedoch die Einrichtung mehrerer virtueller Datenkanäle, den sogenannten Pipes. Jede Pipe endet in einem Endpoint. 48

49 Kapitel 5: Universal Serial Bus (USB) Jedes USB Gerät kann mehrere solcher Endpoints und somit mehrere Pipes unterstützen. Physikalisch gesehen, ist ein Endpoint eine FIFO mit einer festgelegten Tiefe, welche USB Daten empfangen oder senden kann. Bei der Adressierung von USB Daten wird neben der USB Geräte Adresse eine weitere Endpoint Nummer gesendet, wodurch die angesprochene FIFO in einem USB Gerät eindeutig identifiziert ist. Alle USB Geräte müssen einen Control Endpoint (EP0) unterstützen. Dieser Endpoint ist der einzige bidirektionale Endpoint. Über den Control Endpoint können sowohl Daten empfangen als auch gesendet werden. Alle anderen Endpoints arbeiten unidirektional, sie können Daten entweder empfangen oder senden. Die Richtung des Datentransfers wird immer aus Sicht des Host bestimmt. Endpoints, die nur Daten empfangen können, sind Out Endpoints. Out Transfers laufen also immer in Downstream Richtung ab. Wenn Daten in Upstream Richtung zum Host übertragen werden, dann liegt ein In Transfer vor. Endpoint, die nur Daten senden können, sind also immer In Endpoints. Zur Übertragung von Daten sind vier verschiedene Transferarten festgelegt: Control Transfer: Zur Steuerung und Konfiguration eines USB Geräts dient der Control Transfer. Control Transfers sind immer mit dem Endpoint EP0 assoziiert und können deshalb bidirektional ablaufen. Für den Control Transfer sind auf dem Bus bis zu 10% der verfügbaren Bandbreite reserviert. Die Daten werden immer garantiert angeliefert. Da das USB Protokoll ein integrierte Fehlerkorrektur besitzt. Interrupt Transfer: Zur Übertragung von keinen Datenmengen dienen Interrupt Pipes. Typische Anwendungen sind die Statusabfrage von Geräten oder die Übertragung von Tastenschlägen bei Tastaturen. 49

50 Kapitel 5: Universal Serial Bus (USB) Der Begriff Interrup darf an dieser Stelle nicht als extern initiierte Unterbrechung das Prozessors verstanden werden. Da der USB ein Single Master System ist, darf kein Gerät ohne Aufforderung senden. Interrupt Endpoints werden durch den Host zyklisch abgefragt, was sich Polling nennt. Das Polling Intervall kann ein Vielfaches von 1 ms betragen. Innerhalb eines Frames (1 ms) ist ein mehrfaches Abfragen eines Interrupt Endpoints nicht möglich. Für Interrupt Transfers sind bis zu 90% der verfügbaren Bandbreite auf dem Bus reserviert. Sie haben somit einen garantierten Zugriff auf den Bus. Interrupt- Transfers unterliegen der integrierten Fehlerkorrektur des USB Protokolls. Bulk Transfer: Zur Übertragung von großen und Zeit unkritischen Datenmengen dient der Bulk Transfer. Diese Transferart ist für beide Richtungen spezifiziert. Bulk Daten werden nur innerhalb der noch verfügbaren Bandbreite übertragen. Bulk Endpoints werden nur angesprochen, wenn auch wirklich Daten vorhanden sind. Bei Out Richtung beginnt der Host ohne vorherige Ankündigung zu senden. Sollen dagegen Daten über einen Bulk Endpoint in In Richtung transportiert werden, so wird dies meist mit einer Status Meldung über den Interrupt In Endpoint beim Host angemeldet. Bulk Transfer ist nur für Full Speed Geräte spezifiziert. Auch der Bulk Transfer unterliegt der Fehlerkorrektur des USB Protokolls. Die Daten werden somit Fehlerfrei übertragen. Isochronous Transfer: Ein wesentliches Merkmal des USB ist die Unterstützung des Isochronous Transfers. Damit ist die Übertragung von Daten möglich, die eine konstante Bandbreite erfordern. Typische Anwendungsbeispiele sind die Übertragung von Audio- bzw. Videodaten. Der Isochronous Transfer hat immer einen garantierten Zugriff auf den Bus. Zusammen mit den Interrupt Transfers sind bis zu 90% der USB Bandbreite für diese periodische 50

51 Kapitel 5: Universal Serial Bus (USB) Transferarten reserviert. Isochrone Endpoints werden auch nur von Full Speed Geräten unterstützt. Isochrone Datentransfers unterliegen keiner Fehlerbehandlung. Außerdem wird bei der Datenübertragung durch das Empfangsgerät kein Handshake gesendet. Für die praktische Nutzung dieses Übertragungskonzeptes muss dies berücksichtigt werden. Es kommen nur Anwendungen in Frage, für die die Echtzeitübertragung der Daten wichtiger ist als die absolut korrekte Übermittlung. Bei der Übertragung von Audiodaten zu Lautsprechern entsteht kein großer Qualitätsmängel durch den Verlust eines oder mehrerer Samples. Verspätete Daten sind während einer isochronen Übertragung unnütze Daten. 5.4 USB Treiber Schichten Unter Windows 2000 benutzt die USB Kommunikation zwei Arten von Treibern, den Gerätetreiber und den Bustreiber. Ein Gerätetreiber ist für die Kommunikation zuständig, die für ein einzelnes Gerät oder eine Geräteklasse spezifisch ist. Ein einzelnes USB Gerät kann einen oder mehrere Gerätetreiber benutzen. Unterhalb des Gerätetreibers befinden sich drei Treiber, die sich Aspekten der Buskommunikation widmen. In Anlehnung an die USB Topologie heißen die drei Treiber: Hub Treiber, Busklassen Treiber und Host Controller Treiber. 51

52 Kapitel 5: Universal Serial Bus (USB) Abbildung 5.2: USB Treiber Schichten Host Controller Treiber: Die Visualisierung der Hardwarefunktionen des USB Host Controllers für die Windows 2000 Betriebssystemkomponenten erfolgt durch die USB Host Controller Treiber uhcd.sys. Die Schnittstellen des Treibers sind von Microsoft nicht dokumentiert und damit für den Endanwender nicht nutzbar. 52

53 Kapitel 5: Universal Serial Bus (USB) Busklassen Treiber: Zentrale Komponente im USB Treibermodell ist der USB Bustreiber usbd.sys (oft als USB Driver oder USBD bezeichnet). Dieser Treiber erfüllt die folgenden Aufgaben: - Konfiguration: Die Konfiguration der USB Geräte erfolgt über die Control Pipe PE0. Der USB Bustreiber erzeugt für jedes Gerät nach seinem Start durch das Betriebssystem diesen Datenkanal zum EP0. Über diesen Kanal erfolgt die Konfiguration der angeschlossenen Geräte, beginnend an der Wurzel der Baumstruktur. Der Zugriff auf den EP0 durch die Treiberkomponente oder durch Anwendungen ist nur über spezielle Interface Funktionen erlaubt. Der Konfigurationsprozess umfasst die Abfrage der Deskriptoren (Konfigurationsstruktur eines USB Gerätes) und die Zuweisung einer eindeutigen USB Adresse. Unter Nutzung der Deskriptordaten wird auch der dem Gerät zugehörige Treiber lokalisiert und geladen und damit die weitere Konfiguration des Gerätes gestartet. Eine Änderung der damit festgelegten Geräteparameter ist zu jedem Zeitpunkt möglich. - Ressourcenkontrolle: Für jedes angeschlossene USB Gerät muss vom Busklassen Treiber überprüft werden, ob eine fehlerfreie Funktion des Gerätes mit den zur Verfügung stehenden Ressourcen möglich ist. Diese Überprüfung erfolgt während der Konfiguration des Gerätes. Es besteht die Möglichkeit, dass Geräte mehr Leistung benötigen, als an dem jeweiligen Anschlussport zur Verfügung steht. Über Deskriptor Abfragen kann der Leistungsverbrauch der Geräte und die maximal zur Verfügung stehende Leistung an einem Hub Port ermittelt werden. Im Fall eines zu hohen Verbrauchs wird das Gerät nicht konfiguriert und kann damit nicht genutzt werden. Außerdem wird beim Auswählen einer Konfiguration durch den Busklassen Treiber überprüft, ob die benötigten Bandbreiten für alle Pipes garantiert werden können. Die Information über die von einem Endpoint geforderte Bandbreite ist im zugehörigen Deskriptor enthalten. Zu beachten ist, dass sich dieser Wert nur auf die reinen Datenübertragung benötigten Ressourcen bezieht. Vor dem Vergleich mit der verbleibenden Bandbreite muss der Wert um die durch protokollspezifische Daten und Verarbeitungszeit bedingte Ressourcen erhöht werden. 53

54 Kapitel 5: Universal Serial Bus (USB) - Datenflusskontrolle: Der Datentransport zwischen Gerätetreiber und USB Gerät erfolgt aus der Sicht des Gerätetreibers über logische Kanäle (Pipes) und ist daher für diesen nicht an USB spezifische Parameter gebunden. Aufgabe des Busklassen Treibers ist die Anpassung der Datenblöcke des Gerätetreibers an das USB Protokoll und die Überwachung des Status der Datenübertragung. Für isochrone Datenübertragung ermöglicht die USBD Schnittstelle die Konvertierung des Quelldatenstroms in USB spezifische Pakete. Zur Synchronisation der isochronen Daten stehen verschiedene Mechanismen zu Verfügung. - Export von Schnittstellen: Die Schnittstelle des USB Busklassen Treibers in Richtung Usermode ist dokumentiert. Sie bildet den Ausgangspunkt für die Nutzung des USB durch Anwendungen. Für Anwendungsprogramme im Usermode ist ein Zugriff auf diese Schnittstelle nicht direkt möglich. Die Realisierung dieses Zugriffs bedingt den Gerätetreiber, das auf bestimmte Funktionsaufrufe aus dem Usermode reagiert und diese in geeigneter Form an den USB Busklassen Treiber weiterreicht. Die Kommunikation mit USB Geräten erfolgt über zwei unterschiedlicher Mechanismen. Der erste Mechanismus ist der Pipe Mechanismus. Die Bereitstellung von Kommunikationskanälen (Pipes) zu den Endpoints der entsprechenden USB Geräte ermöglicht den Austausch von gerätespezifischen Daten und Kontrollinformationen. Zugriffe auf den EP0 sind nur durch spezielle Funktionsaufrufe möglich. Damit wird sichergestellt, dass sich verschiedene Geräte nicht gegenseitig beeinflussen und der Datenverkehr zum EP0 jederzeit der USB Spezifikation genügt. Der zweite Mechanismus ist der Kommando Mechanismus. Vordefinierte Kommandos ermöglichen es den Gerätetreiber, den USB Busklassen Treiber und damit die entsprechenden USB Geräte zu konfigurieren und grundlegende Steueraufgaben zu realisieren. In einigen Fällen wird dazu zusätzlich der Pipe Mechanismus benutzt. Hub Treiber: Die baumförmige Struktur des USB wird durch Hubs realisiert und organisiert. Die Konfiguration der Hubs und die damit verbundene dynamische Verwaltung der Baumstruktur übernimmt das Modul usbhub.sys. Die wichtigsten Aufgaben des Hub 54

55 Kapitel 5: Universal Serial Bus (USB) Treibers umfassen die Konfiguration der Hubs (unter anderem Statusabfrage aller Ports, Freischalten einzelner Ports) und die Kontrolle der Stromversorgung der Ports. Human Interface Device (HID) Treiber: Geräte der Human Interface Device (HID) Klasse werden von Windows 2000 voll unterstützt. Mit Hilfe des HID Klassen Treibers hidclass.sys und des HID Bus Treibers hidusb.sys können Anwendungen API Aufrufe zur Identifizierung der Geräte, das Lesen und Schreiben allgemeiner einsetzten. Die Daten werden in so genannten Reports umgewandelt. Die HID Klasse verfügt über definierte Report Typen für Mäuse, Tastaturen und Joysticks. Alternativ können sie ihr eigenes Format festlegen. Geräte der HID Klasse müssen keine Standardperipheriegeräte sein und brauchen noch nicht einmal wirklich Schnittstellen zum Menschen darzustellen. Die einzige Anforderung ist die, dass die im Gerät gespeicherten Deskriptoren den entsprechenden Anforderungen der HID Klasse gerecht werden müssen und dass die Geräte Daten mit Interrupt- oder Control Transfer in Übereinstimmung mit den Definitionen in der HID Spezifikation senden und empfangen müssen. Gerätetreiber: Da auf das Interface des USB Busklassen Treibers von Anwendungen nicht direkt zugegriffen werden kann, werden zusätzliche Gerätetreiber benötigt. Der I/O-Manager von Windows 2000 erzeugt entsprechend den Anforderungen der Anwendungen IRPs und sendet diese an den entsprechenden Gerätetreiber. Aufgabe des Gerätetreibers ist die Ergänzung dieser IRPs mit zusätzlichen Informationen, welche in USB Request Blocks (URB) zusammengefasst werden und die Übergabe dieser IRPs an den USBD. Die Verwendung von URBs erleichtert die korrekte Bedienung der Schnittstelle des USBD und ermöglicht den Zugriff auf die durch die USB Host Software (USBD) zur Verfügung gestellten Mechanismen. Weitere Aufgaben der gerätespezifischen Treiber sind die Konfiguration der Geräte, die Behandlung von auftretenden Fehlern und die Realisierung von Plag&Play und Power Management Funktionalitäten. Kenntnisse über konkrete Umsetzung von Daten- und Kontrollfluss durch das Betriebssystem sind für das Erstellen dieser Treiber nicht notwendig. Aus Sicht der USB Gerätetreiber stellen USB Geräte eine 55

56 Kapitel 5: Universal Serial Bus (USB) Sammlung von Endpoints dar, auf die zur Kommunikation mit dem entsprechenden Geräten über vorhandene Kanäle (Pipes) zugegriffen werden kann. 5.5 Schnittstelle des USB Bustreibers USBD Die Kommunikation zwischen USB Gerätetreiber und USB Bustreiber erfolgt auf der Basis der schon ausführlich beschriebenen I/O Request Packets (IRP) und der USB Request Blocks (URB). URB ist eine Struktur die den Kommunikationsfluss zum USB Bustreiber übernimmt. Die Struktur des URB wird später in dem Kapitel noch ausführlicher beschrieben. Abbildung 5.3: Komponenten der USBD Schnittstelle Erzeugung eines URB: Die USB spezifischen Parameter eines I/O-Vorgangs werden in einem URB zusammengefasst. Ein URB ist für die meisten Aufrufe des USBD notwendig. Entsprechend der auszuführenden Aktion wird ein URB erzeugt und mit den erforderlichen Parametern gefüllt. 56

57 Kapitel 5: Universal Serial Bus (USB) Bearbeitung des IRP: Kommunikationsvorgänge zwischen Gerätetreibern basieren auf IRPs. Der über dem USBD liegende Gerätetreiber empfängt innerhalb eines solchen Vorgangs ein IRP vom I/O-Manager. In diesem IRP ist für jede Treiberschicht ein Speicherplatz für spezifische, dieser Schicht zugeordnete Parameter vorhanden. Zum Aufruf des USBD ermittelt der aufrufende Treiber die Adresse des Speicherplatzes (IoGetNextIrpStackLocation()), welcher dem USBD zugeordnet ist, und fügt dort die entsprechenden Informationen ein (zum Beispiel: I/O Control Code oder URB). Um die synchrone Bearbeitung des IRP innerhalb des Treibers zu ermöglichen, wird ein Synchronisationsobjekt vereinbart (IoSetCompletionRoutine()). An der Schnittstelle zum USBD stehen unter anderem folgende I/O Conrol Codes zur Verügung: IOCTL_INTERNAL_USB_SUBMIT_URB IOCTL_INTERNAL_USB_RESET_PORT IOCTL_INTERNAL_USB_ENUMERATE IOCTL_INTERNAL_USB_GET_ROOTHUB_PDO Alle I/O Control Codes sind in der Datei usbioctl.h definiert und dokumentiert. Aufruf des USBD: Mit dem Befehl IoCallDriver() wird das IRP und damit der URB an den USBD übergeben. in den meisten Fällen benötigt dieser Funktionsaufruf einige Zeit zur Ausführung, so das ein dementsprechender Statuscode zurück gegeben wird. Nach Signalisierung der abgeschlossenen Bearbeitung des IRP durch den USBD unter Nutzung des Synchronisationsobjektes kann der darüber liegende Gerätetreiber weitere Aktionen innerhalb dieses I/O-Vorgangs ausführen. Übergabeparameter: Die Festlegung der bei einem USBD Aufruf angesprochenen Funktion des Bustreibers erfolgt durch einen Funktionscode, welcher im URB Header gespeichert ist. 57

58 Kapitel 5: Universal Serial Bus (USB) Diese Funktionscodes können in vier Gruppen eingeteilt werden, die folgende Aufgabe erfüllen: - Konfiguration der Geräte - USB Frame Kontrolle - Pipe Kontrolle - Geräte Kontrolle Voraussetzung für die Kommunikation mit einem Endpoint aus Sicht eines USB Gerätetreibers ist die Zugriffsmöglichkeit auf den Kanal zu diesem Endpoint. Dieser Zugriffspunkt wird durch das Pipe Handle repräsentiert. Die Zuordnung der Pipe Handle erfolgt während der Konfiguration des Gerätes durch den USBD. Die Information über den Status eines I/O-Vorgangs wird durch USBD Statuscodes visualisiert, welche in vier übergeordneten Kategorien eingeteilt sind. Innerhalb der Statuskategorien geben die verschiedenen Statuscodes genau Informationen über die Art des Fehlers. Eine besondere Stellung nimmt die Fehlercode Kategorie USBD_STATUS_HALTED ein. Bei Beendigung einer Anforderung mit diesem Fehler ist der angesprochene Endpoint deaktiviert und die damit verbundene Pipe vorübergehend nicht nutzbar. Es müssen zusätzliche Aktionen durchgeführt werden, um die volle Funktionsfähigkeit dieser Pipe wieder herzustellen. Unter Nutzung des Funktionscodes URB_FUNCTION_RESET_PIPE kann der Fehlerzustand wieder aufgehoben werden. Datentransport: Der angeforderte Transport von Daten zwischen Gerät und Anwendung wird dem Gerätetreiber durch ein IRP mit dem Funktionscode IRP_MJ_READ bzw. IRP_MJ_WRITE signalisiert. In der mit dem Einstiegspunkt für diese Funktionscodes verbundene Dispatch Funktion werden alle für Datentransporte notwendigen Aktionen zusammengefasst. Voraussetzung für den Austausch von Daten ist die Zugriffsmöglichkeit auf einen Kommunikationskanal zum jeweils angesprochenen Endpoint. Dafür stehen Pipe Handles zur Verfügung, die während der StartDevice Phase für jedes Interface des Gerätes in einer Struktur des Typs USBD_INTERFACE_INFORMATION abgelegt werden. In dieser Struktur sind 58

59 Kapitel 5: Universal Serial Bus (USB) neben dem Pipe Handle noch weitere wichtige Informationen wie zum Beispiel der Typ der entsprechenden Pipe enthalten. Unter Nutzung der ermittelten Informationen wird ein URB erstellt. Zum Datentransport stehen die Funktionscodes URB_FUNCTION_ISOCH_TRANSFER und URB_FUNKTION_BULK_OR_INTERRUPT_TRANSFER und die zugehörigen Strukturen zur Verfügung. Zur Realisierung eines effizienten Datentransports sollte die Bearbeitung der entsprechenden I/O-Anforderung im Treiber asynchron und unter Verwendung der Methode Direct I/O-Processing (DIO) erfolgen. 5.6 USB Request Block (URB) Die Kommunikation zwischen den Komponenten des USB Treibermodells erfolgt auf der Basis der schon ausführlich beschriebenen I/O Request Packets (IRP). Die Koordination des Informationsflusses ist Aufgabe des I/O-Managers. Alle Parameter einer USB I/O-Anforderung werden in einer Struktur zusammengefasst, die als USB Request Block (URB) bezeichnet wird. Der Aufbau dieser Struktur wird durch die jeweilige I/O-Anforderung bestimmt. Ein URB wird über einen Zeiger an ein IRP an der Stelle Parameters.Others.Argument1 angefügt. Die vollständige Deklaration der URB Struktur kann man in der Datei usbdi.h finden. 59

60 Kapitel 5: Universal Serial Bus (USB) Abbildung 5.4: URB Struktur Die Struktur UrbHeader enthält Informationen über die Größe des URB und den Funktionscode für den I/O-Vorgang. Die Größe des URB ist wegen dem von der aktuell auszuführenden Funktion abhängigem Aufbau nicht konstant und muss in jedem Fall neu bestimmt werden. Innerhalb des URB Header werden Statusinformationen über den Erfolg der Anforderungen übergeben. Ein URB wird aus der Kombination eines URB Headers und einer funktionsspezifischen Struktur aufgebaut. Dazu ist an der ersten Position jeder Funktionsstruktur ein URB Header eingefügt. Durch Bildung einer Union aus Header und veränderlichen Zusatzdaten wird der auf eine spezielle Funktion abgestimmte Aufbau eines URB mit geringem Aufwand möglich. 60

61 Kapitel 5: Universal Serial Bus (USB) Für die Erzeugung eines URB bestehen zwei Möglichkeiten. Der gemeinsame erste Schritt ist in beiden Fällen das Reservieren der benötigten Menge an Systemspeicher. Diese ist abhängig von der auszuführenden Funktion bzw. der damit verbundenen Struktur. Eine Möglichkeit zum Setzen der Parameter innerhalb eines URB ist die direkte Zuweisung der Werte. Als Alternative zum direkten Setzen der Parameter kann ein URB durch den Aufruf von vordefinierten Makros oder Bibliotheksbefehlen gefüllt werden. Einige URBs bestehen aus variablen Feldern bestimmter Datenstrukturen (UrbBulkOrInterruptTransfer). Somit hängt ihre Größe nicht nur vom Funktionscode, sondern auch von den zu bearbeitenden Daten ab. Für die Erzeugung dieser URB stehen Bibliotheksfunktionen zur Verfügung, welche den erforderlichen Speicher allokieren und die Datenstrukturen initialisieren. Eine Kombination aus Makro- und Funktionsaufrufen und direkter Zuweisung einzelner Parameter ist ebenfalls möglich. 61

62 Kapitel 6: Hardware 6. Hardware Die Hardware ist ein modifizierter Datenlogger der Firma IMC elektronische Baugruppen GmbH. Die Funktion des Datenloggers ist es, Daten von zwei unterschiedlichen Bussystemen gleichzeitig in Echtzeit auf eine interne Festplatte aufzuzeichnen. Der Datenlogger verfügt über einen optischen Anschluss für den Media Orientated System Transport (MOST) Ring. Dazu können noch vier High Speed und ein Low Speed Controller Area Network (CAN) Busse angeschlossen werden. Die so auf der Festplatte gespeicherten Daten können über USB an einen Rechner übertragen und weiterverarbeitet werden. Abbildung 6.1: Datenlogger Die zwei für die Arbeit mit dem USB wichtigsten Komponenten sind zum einen ein USB Baustein und ein Mikrocontroller. 62

63 Kapitel 6: Hardware 6.1 USB Baustein Der USB Baustein mit der Bezeichnung PDIUSBD12 von Philips wurde auf dem Datenlogger verbaut. Dieser Baustein stellt die physikalische Verbindung zum USB her. Er muss die differentiellen Signalpegel auf den Datenleitungen D+ und D- entsprechend der Spezifikation senden und empfangen können. Die einzelnen Bits werden mit Hilfe von Non Return to Zero (NRZ) kodiert. Eine Fehlerüberwachung der einzelnen Bits wird mit Cyclic Redundanc Check (CRC) durchgeführt. Auf den USB Bausteinen werden First In First Out (FIFO) Buffer verwendet um die noch zu sendenden Daten bzw. die bereits empfangen Daten zwischen zuspeichern. Um mit einem Mikrocontroller Daten auszutauschen, hat der PDIUSBD12 eine 8 Bit breite parallele Schnittstelle. Außerdem verfügt der Baustein noch über drei weitere Steuer Eingänge und einem Interrupt Ausgang. 6.2 Mikrocontroller Der verwendete Mikrocontroller ist der FPSLIC AT94K40AL von Atmel. Dieser Baustein vereint ein Field Programmable Gate Array (FPGA) und einen 8 Bit Reduced Instruction Set Computer (RISC). In Verbindung mit dem USB wird nur die Funktionalität des RISC Mikrocontrollers benötigt. Die für den Controller programmierte Software (Firmware) muss in der Lage sein, vom Host übermittelte Geräte Anfragen zu erkennen, zu bearbeiten und zu beantworten. Der FPSLIC besitzt auch eine serielle Schnittstelle (RS232). Mit ihr kann man diverse Information zu einem Rechner übertragen. Diese Information kann man dann zur Fehleranalyse einsetzten (siehe Kapitel 7.4.3). 63

64 Kapitel 7: Programmierung des USB Treibers 7. Programmierung des USB Treibers Kernelmode Code zu schreiben, ist schon etwas anspruchsvoller als die Programmierung gewöhnlicher Anwendungen. Schließlich handelt es sich bei einem Treiber um eine Komponente des Betriebssystems die dessen uneingeschränktes Vertrauen genießt. Treibercode will daher nicht nur sorgfältig geplant und geschrieben sein, sondern erfordert auch die Einhaltung einiger Konventionen. 7.1 Techniken der Treiberentwicklung Verzicht auf Assemblercode: Quelltexte, die Teile in Assembler enthalten, sind schwer zu lesen, nicht portierbar und schwierig zu warten. Hinsichtlich der Ausführungsgeschwindigkeit ist die Programmiersprache C/C++ nicht viel langsamer als Assembler. Außerdem lässt sich der sichere Zugriff auf I/O Register von Geräten ohnehin nur über die HAL Makros bewerkstelligen. Plattformspezifischer Code Plattformspezifischer Code gehört nach Möglichkeit in ein gesondertes Modul. Es sollte über die Direktiven #ifdef und #endif geklammert sein. Keine C-Laufzeitbibliotheken Treiber sollten generell nicht mit der standardmäßigen C-Laufzeitbibliothek gebunden werden. Dies würde zu erheblicher Systemspeicherverschwendung führen. Jedoch unterstützt Windows 2000 speziell für Kernelmode Code eine eigene rudimentäre Laufzeitumgebung (Runtime Library). 64

65 Kapitel 7: Programmierung des USB Treibers Benennungskonventionen Für alle größeren Software Projekte ist es ratsam, eine Benennungskonvention einzuführen, die die Bezeichnerwahl für Routinen und Daten projektweit regelt. Die strikte Einhaltung einer Benennungskonvention kann die Entwicklung und Wartung von Treibern erheblich beschleunigen, weil sie die Durchführung von Tests ebenso wie die Fehlersuche enorm vereinfacht. Für den Einsatz des Driver Development Kit (DDK) bietet sich die Benennungskonvention von Microsoft an. Eine Header Datei namens ntddk.h definiert alle Datentypen, Strukturen, Konstanten und Makros, die für elementare Kernelmode Treiber eine Rolle spielen. Die DDK Konvention sieht die Großschreibung all dieser Bezeichnerarten vor. Selbst für die elementaren Datentypen der Sprache C sind spezifische DDK Bezeichner vorgesehen. So vereinbart die Datei ntddk.h den C Datentyp void* beispielsweise als PVOID. Microsoft empfiehlt weiterhin, ein treiberspezifisches Präfix für die Benennung der standardmäßigen Treiberroutinen zu verwalten Betriebssystemfunktionen Windows 2000 stellt im Kernelmodus eine große Anzahl verschiedener Funktionen zur Verfügung. Abhängig von dem Modul, das die Funktionen zur Verfügung stellt, kann man mehrere Kategorien unterscheiden. 65

66 Kapitel 7: Programmierung des USB Treibers Die Tabelle ist aus dem Buch Gerätetreiber unter Windows 2000 und gibt einen groben Überblick über die vorhandenen Funktionen und Kategorien: Kategorie Funktionen für Funktionsnamen Ausführungsschicht Speicherreservierung, ExXxx() Interlocked Queues, Lookaside Lists, System Worker Threads Hardware Abstraktionsschicht Zugriff auf Geräteregister, HalXxx() Buszugriffe I/O-Manager Generelle IoXxx() Treiberunterstützung Kernel Synchronisation, DPCs KeXxx() Speicher Manager virtuelles auf MmXxx() physikalisches Mapping, Speicherreservierung Objekt Manager Management von Handles ObXxx() Process Manager Management von System PsXxx() Threads Laufzeitbibliothek String Manipulation, RtlXxx() (meist) Arithmetikfunktionen, Zugriff auf die Registry, Sicherheitsfunktionen, Zeitund Datumsfunktionen, Queue und Listenfunktionen Sicherheitsüberwachung Privilegierungsüberprüfung, SeXxx() Security descriptor Funktionen Alle Interne Systemdienste ZwXxx() 66

67 Kapitel 7: Programmierung des USB Treibers 7.2 Softwareumgebung Die Wahl der Softwareumgebung bestand zwischen einem Kommandozeilen Compiler und Visual C++. Der Kommandozeilen Compiler und Linker BUILD ist Bestandteil des Windows 2000 Driver Development Kit (DDK). Mit diesem Compiler kann man die fülle an Beispieltreiber im DDK kompilieren. Doch Aufgrund der umständlichen Kommandozeilen Eingabe ist BUILD nicht zu empfehlen. Aus diesem Grund ist Visual C++ vorzuziehen. Visual Studio bietet auch bei der Projektverwaltung gut Dienste Windows 2000 DDK Um einen Treiber für Windows 2000 nach WDM programmieren zu können, bietet Microsoft kostenlos das Windows 2000 DDK zum Download an. Das DDK installiert sich auf der Festplatte und registriert die Include (inc) und library (lib) Verzeichnisse in den Umgebungsvariablen des Betriebssystems. Dieses Software Paket enthält unter anderem die wichtige Treiber und Geräte Struktur. In zahlreichen Header Dateien definiert das DDK diese und weitere Strukturen, Datentypen, Makros und Konstanten. Außerdem sind auch Treiberspezifische Bibliotheken in dem Kit enthalten. Des weiteren werden im dem DDK diverse Tools zur Treiber Erstellung (BUILD) bis hin zum Debugging (WinDbg) bereitgestellt. Die zahlreichen Beispieltreiber veranschaulichen dem Einsteiger das komplexe Thema an kompilierbaren Code. Die Beispiele lassen sich allerdings nur mit dem BUILD Compiler übersetzen. 67

68 Kapitel 7: Programmierung des USB Treibers Microsoft Visual Studio 6 Obwohl Visual Studio in erster Linie als Werkzeug zur Entwicklung von Anwendungen in C++ angewandt wird, lässt sich Visual Studio auch ohne weiteres für das Erstellen von Kernelmode Treibern verwenden. Bevor man jedoch beginnt einen Treiber zu schreiben, müssen eine Reihe an Projekt Einstellungen vorgenommen werden. Um diese aufwendigen Einstellungen nicht selber vornehmen zu müssen gibt es auf der Begleit-CD von dem Buch Gerätetreiber unter Windows 2000 einen Assistenten für Visual Studio. Dieser Assistent (DDAppWiz.awx) setzt die Compiler- und Linkerschalter für die Erstellung von Treibern automatisch. Wie in dem Buch Gerätetreiber unter Windows 2000 zu entnehmen ist nimmt der Assistent folgende Projekteinstellungsänderungen vor: Präprozessor Symbole: Der Assistent löscht WIN32, _WINDOWS, _MBCS und _DEBUG Präprozessor Symbole und DBG, _X68_ und WIN32_WINNT=0x500 Symbole werden hinzugefügt. Compilerschalter: DDAppWiz löscht die Compilerschalter /GX, -GX und /GZ. Hinzugefügt wird dagegen Gz. Include Diektive für den Compiler: Der Assistent erweitert die Liste der nach Header Dateien zu durchsuchenden Verzeichnisse um zwei Einträge für die Dateien des DDKs (\NTDDK\inc und \NTDDK\inc\ddk). Bei abweichendem Installationsort des DDK müssen diese Beiden Verzeichnisnamen angepasst werden. Linker: Der Assistent entfernt sämtliche Win32 Standardbibliotheken aus der Kommandozeile des Linkers und setzt an ihrer Stelle die int64.lib, ntoskrnl.lib und hal.lib Bibliotheken des DDKs. Des Weiteren fügt er der Kommandozeile für den Linker die Schalter 68

69 Kapitel 7: Programmierung des USB Treibers /node-faultlib, -driver, -subsystem:native,5.00, -base:0x10000 und entry:driverentry hinzu. Bei den Linker Optionen wird nur /subsystem:windows gelöscht. Microsoft Foundation Classes (MFC): Damit der Compiler nicht versehentlich versucht, einen Treiber auf den ausschließlich in Win32 Anwendungen einsetzbaren Microsoft Foundation Classes (MFC) aufzubauen, setzt der Assistent diese Option zurück. 7.3 Installation des Treibers Um den nun fertig übersetzten Treiber testen zu können, müssen folgende Einstellungen im System durchgeführt werden: - Die Systemregistrierung wird um Schlüssel und Werteinträge erweitert. - Die Treiberdatei in entsprechenden Unterverzeichnissen des Systems laden. Diese Einstellungen kann man manuell oder auch automatisiert durchführen. Die manuelle Installation ist nicht vorzuziehen, weil sich der Endanwender gut mit der Systemregistrierung von Windows 2000 auskennen muss. Es wird deshalb hier die automatisierte Installation beschrieben. Die automatisierte Installation eines Treibers wird von einer Textdatei mit der Namenserweiterung INF gesteuert. INF Dateien werden üblicherweise zusammen mit der Hardware und dem dazugehörigen Treiber auf Diskette oder CD ausgeliefert. Für Struktur und Inhalt ist der Treiberprogrammierer zuständig und nicht der Endanwender Aufbau der INF Datei INF Dateien sind einfache, in Abschnitte unterteilte Textdateien. Abschnitte beginnen mit in eckigen Klammern gesetzten Bezeichner, der dem folgendem Text einen 69

70 Kapitel 7: Programmierung des USB Treibers Abschnittsnamen gibt. Einige Abschnittsnamen werden von Windows 2000 vorausgesetzt andere sind dagegen frei wählbar. Die Reihenfolge der Abschnitte ist weitgehend beliebig, da jeder Abschnitt einen eigenen individuellen Namen haben muss. Nach dem Abschnittsnamen kommt ein oder mehrere Einträge. Einem Eintrag kann wiederum ein oder mehrere Werte zugewiesen werden. Ein Eintrag muss innerhalb des jeweiligen Abschnitts einzigartig sein. Direktiven wie AddReg oder CopyFiles können dagegen in einem Abschnitt beliebig oft erscheinen. Wenn Abschnittsnamen als Werte von Einträgen erscheinen, ergibt sich eine Verknüpfung zwischen verschiedenen Abschnitten. Abbildung 7.1: Aufbau der INF Datei Sowohl Einträge als auch ihre Werte lassen sich bei Bedarf über Platzhalter der Form %Platzhalter% angeben. Die von Windows 2000 vorausgesetzten Abschnitte werden jetzt näher erklärt: Version Abschnitt: Üblicherweise beginnt eine INF Datei mit dem [Version] Abschnitt. Dieser Abschnitt dient als Kopf und Signatur der gesamten Datei. 70

71 Kapitel 7: Programmierung des USB Treibers Es gibt eine viel Zahl von Einträgen: Signature Class ClassGUID Provider LayoutFile CatalogFile DriverVer Das wichtigste Feld in diesem Abschnitt ist das ClassGUID. Der Global Unique Identifer (GUID) ist eine für das Gerät einzigartiger Code, der den Zusammenhang zwischen Treiber und der INF Datei herstellt. Der GUID wird in der Systemregistrierung eingetragen und beim Laden das Treibers überprüft der I/O-Manager den Eintrag in der Systemregistrierung mit dem GUID vom Treiber. So wird sichergestellt das immer der richtige Treiber geladen wird. Manufacturer Abschnitt: Sein Eintrag listet die von der INF Datei installiertes Gerät auf. Die allgemeine Form das Abschnitts ist: Hersteller=Install-Abschnitt, VID&PID Unter Hersteller trägt man den Hersteller des Treibers bzw. der Hardware ein. Install- Abschnitt steht für den Namen eines weiteren Abschnitts der INF Datei der als [DDInstall] bezeichnet wird. Die zwei Identifikatoren, Vendor Identifier (VID) und Product Identifier (PID) sind sehr wichtig. Diese zwei in der Kombination einzigartigen Identifikatoren stellen einen Bezug zwischen dem Gerät und der INF Datei bzw. dem Treiber her. DDInstall Abschnitt: [DDInstall] ist ein zusammenfassender Bezeichner. Die INF Datei muss für jedes Gerät und jeden Treiber einen eigenen Abschnitt dieser Art enthalten. Unter diesen Abschnitten sind folgende zwei Einträge notwendig. 71

72 Kapitel 7: Programmierung des USB Treibers - AddReg Eintrag: Dieser Eintrag weist dem Hardwareassistenten an, neue Einträge in der Systemregistrierung zu erzeugen bzw. existierende Einträge zu modifizieren. Das allgemeine Format des Eintrags ist: AddReg=Teilbaum (, Schlüsselname, Wertname, Flags, Wert) Als Teilbaum sind folgende Werte zulässig: HKCR HKEY_CLASSES_ROOT HKCU HKEY_CURRENT_USER HKLM HKEY_LOCAL_MACHINE HKU HKEY_USERS HKR Hardware Teilschlüssel für das installierende Gerät Schlüsselname, Wertname, Flags und Wert sind Einstellungen in der Systemregistrierung die im jeweiligen Teilbaum vorgenommen werden sollen. - CopyFiles Eintrag: Das allgemeine Format des CopyFiles Eintrags lautet: CopyFiles=Ziel-Dateiname (, Quell-Dateiname, Flag) Als Ziel-Dateiname ist der Name einzutragen, unter dem die Datei nach Abschluss der Installation auf dem Zielsystem erscheinen soll. Wenn die Datei auf dem Installationsmedium einen anderen Namen hat, dann ist dieser in Quell-Dateiname anzugeben. Flag bestimmt das Verhalten des Hardwareassistenten vor allem dann, wenn bereits eine ältere Version der Zieldatei auf dem System existiert Hardwareassistent Der Hardwareassistent stellt eine Benutzerschnittstelle des I/O-Managers dar. Wenn ein Geräte angeschlossen wird, übermittelt das Gerät die VID und PID. Diese beiden Identifikatoren werden in der Systemregistrierung durchsucht. Falls die beiden Identifikatoren in ihrer Kombination nicht gefunden werden fordert der Hardwareassistent den Benutzer auf den Treiber mit Hilfe der INF Datei zu installieren. Wurden dagegen die beiden Identifikatoren gefunden sucht er über die INF Datei und GUID den passenden 72

73 Kapitel 7: Programmierung des USB Treibers Treiber. Der Installationsprozess des Hardwareassistenten ist somit abgeschlossen und der Treiber führt seine Installationsroutinen aus. 7.4 Debugging Die Fehlersuche in Gerätetreibern erfordert spezielle Mechanismen, die sich von den bei normalen Anwendungen verwendeten unterscheiden. Gerätetreiber sind Systemkomponenten. Fehler im Programmcode wirken sich nicht nur auf eine oder mehrere Anwendungen aus. Im Fehlerfall wird die Stabilität des Gesamtsystems beeinträchtigt. Datenverlust oder die möglicherweise irreparable Zerstörung des gesamten Systems können die Folge sein WinDbg Das Microsoft Debug Programm WinDbg ist im Windows 2000 DDK enthalten. WinDbg bietet eine komplette Debug Umgebung für Anwendungen und Gerätetreiber. Bei dem Test von Gerätetreibern mit WinDbg werden zwei Rechner benötigt. Auf dem sogenannten Ziel Rechner läuft der Gerätetreiber und auf dem Host Rechner läuft WinDbg. Die Beiden PCs sind über ein Nullmodem Kabel (Serielle Schnittstelle) miteinander verbunden. Zur Unterstützung dieser Kommunikation müssen auf beiden PCs Symbol-Dateien für alle zu testenden Module, an einer definierten Stelle in der Verzeichnisstruktur, vorhanden sein. In der Testphase stehen bei WinDbg komfortable Möglichkeiten zur Verfügung. WinDbg stellt mit Breakpoints und Fehlerüberwachung ein sehr mächtiges Debugging Werkzeug dar. Diese Testumgebung ist aber nur schwer in Betrieb zu nehmen. Daher wurde eine andere Vorgehensweise um Debugging Information visuell sichtbar zu machen benutzt. 73

74 Kapitel 7: Programmierung des USB Treibers KdPrint mit DebugView Die Ausgabe von Debug Meldungen über KdPrint() Anweisungen ist eine sehr einfach zu realisierende Möglichkeit Treiberinformation auf dem Bildschirm sichtbar zu machen. Die Syntax von KdPrint() entspricht der aus normalen Anwendung bekannten printf() Funktion. Wie bei printf() können auch bei KdPrint() formatierte Argumente übergeben werden. Die Anzeige auf dem Bildschirm geschieht über das Freeware Tool DebugView von Sysinternals. Mit DebugView lassen sich die mit KdPrint() erzeugten Debug Ausgaben auf dem Bildschirm anzeigen oder in einer Datei Speichern. Somit ist es leicht möglich einen Überblick des Ablaufs zu bekommen Ausgaben mit Hilfe vom Hyperterminal Das USB Gerät besitzt ein USB Baustein und einen Mikrocontroller. Der Mikrocontroller liest die Daten von dem USB Baustein und verarbeitet diese weiter. Die Daten die der Mikrocontroller empfängt, kann er auch über die serielle Schnittstelle RS232 wieder ausgeben. Mit dem bei Windows 2000 mitgelieferten Hyperterminal kann man diese Informationen vom Rechner auslesen. Der umgekehrte Weg Daten vom Rechner zum USB Gerät zu übertragen ist natürlich auch möglich. Diese Debug Möglichkeit ist sehr flexibel, denn man kann Dank des programmierbaren Mikrocontrollers jegliche Informationen auf dem Hyperterminal anzeigen lassen Blue Screen of Death (BSD) Nachdem der Treibercode im Kernelmode läuft, versagen jegliche Sicherheitsmechanismen des Betriebssystems. Ein Fehler im Gerätetreiber kann somit das Betriebssystem zum Absturz bringen. Obwohl es unzählige Möglichkeiten gibt, durch eine falsche Treiberlogik Systemabstürze zu provozieren, lassen sich die meisten auf schlichte Adressierungsfehler zurückführen. Systemzusammenbrüche werden unter Windows als Stop Meldungen 74

75 Kapitel 7: Programmierung des USB Treibers bezeichnet. Diese Stop Meldungen erscheinen im Textmodus in weißer Schrift auf blauen Hintergrund, was im letztendlich dem Namen Blue Screen of Death (BSD) beschert hat. Die Stop Meldung enthält bei Windows 2000 nur noch drei Zeilen an Information. In der ersten Zeile erschient der Bugcheck Code. Eine vollständige Referenz der Bugcheck Codes findet man in der DDK Dokumentation. Die zweite Zeile gibt für den Fehlercode definierte Symbol wieder. Die dritte Zeile gibt weiterhin die Adresse der Maschinenanweisung wieder, bei der der Fehler aufgetreten ist, und spezifiziert neben der Systemzeit auch noch den Namen des Treibers, das für den Fehler verantwortlich ist. 75

76 Kapitel 8: Beispieltreiber 8. Beispieltreiber Im folgenden sollen die theoretischen Grundlagen aus den vorhergehenden Kapiteln in die Praxis umgesetzt werden. An ausgewählten Beispielen wird die Programmierung von Kernelmode Treibern demonstriert. Der Beispieltreiber enthält viele Codesegmente von dem Beispieltreiber Bulkusb aus dem DDK. Dieses Vorgehen ist von Microsoft sogar erwünscht um ein möglichst stabilen Treiber und damit auch Betriebssystem zu ermöglichen. Die Hauptprozeduren wurden größten Teils beibehalten. Gerätespezifische Änderungen mussten jedoch vorgenommen werden. 8.1 Haupteinstiegspunkte Was bei normalen Anwendungen die main() Routine ist, ist bei Treibern die DriverEnrty(). Der I/O-Manager ruft die DriverEntry() beim Laden des Treibers auf. NTSTATUS DriverEntry( IN PDRIVER_OBJECT DriverObject, IN PUNICODE_STRING RegistryPath) { NTSTATUS ntstatus = STATUS_SUCCESS; PDEVICE_OBJECT deviceobject = NULL; #if DBG USB_GetRegistryDword( USB_REGISTRY_PARAMETERS_PATH, L"DebugLevel", &gdebuglevel); #endif USB_KdPrint( DBGLVL_DEFAULT,("Entering DriverEntry()\n")); USB_KdPrint( DBGLVL_DEFAULT,("Registry Pfad: %ws\n", RegistryPath->Buffer )); DriverObject->MajorFunction[IRP_MJ_CREATE] = USB_Create; DriverObject->MajorFunction[IRP_MJ_CLOSE] = USB_Close; DriverObject->DriverUnload = USB_Unload; DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = USB_ProcessIOCTL; DriverObject->MajorFunction[IRP_MJ_WRITE] = USB_Write; DriverObject->MajorFunction[IRP_MJ_READ] = USB_Read; DriverObject->MajorFunction[IRP_MJ_SYSTEM_CONTROL] = USB_ProcessSysControlIrp; DriverObject->MajorFunction[IRP_MJ_PNP] = USB_ProcessPnPIrp; DriverObjec t->majorfunction[irp_mj_power] = USB_ProcessPowerIrp; DriverObject->DriverExtension->AddDevice = USB_PnPAddDevice; USB_KdPrint( DBGLVL_DEFAULT,("Exiting DriverEntry(%x)\n", ntstatus)); return ntstatus; } 76

77 Kapitel 8: Beispieltreiber Beim Aufruf bekommt die DriverEntry() Routine einen Zeiger des Treiber Objektes (DriverObject) übergeben. Der pseudo IN Datentyp ist nur eine Konvention vom DDK und soll dem Programmierer anzeigen, das dieser Parameter der Routine übergeben wird. Ein weiterer Parameter den der I/O-Manager der Routine zur Verfügung stellt ist der Registrierungspfad (RegistryPath) zum Service Schlüssel des Treibers. DBG ist eine Globale Variable des Betriebssystems. Dessen Wert ist 0, wenn Windows 2000 im normalen Modus läuft. Ist der Wert dagegen auf 1 so läuft das System im Debug Modus. Der Debug Modus kann entweder beim Booten des Systems aktiviert werden oder bei Visual Studio unter Projekt, Einstellungen mit der Kategorie Debug unter der Karte Linker lässt sich Debug-Info aktivieren. Die USB_GetRegistryDword() Funktion wird demnach nur im Debug Modus aufgerufen. Diese Funktion liest aus dem Registrierungspfad den DebugLevel des Systems. Die nächsten beiden Anweisungen (USB_KdPrint()) sind für Debug Ausgaben, die mit DebugView angezeigt werden können. USB_KdPrint() hat einen Parameter mehr als KdPrint(). Mit dem Parameter (DBGLVL_DEFAULT) können zum Beispiel nur Debug Ausgaben zugelassen werden, wenn das System im Debug Modus ist. Jetzt kommen die eigentlichen Haupteinstiegspunkte, die auch Dispatch Routinen genannt werden. Wie bereits ausführlich erwähnt, werden alle I\O Operationen von Windows 2000 durch die IRPs gesteuert. Der I/O-Manager erzeugt das IRP und schreibt einen Funktionscode in das Feld MajorFunction. Diese Funktionscode Tabelle legt fest welche Dispatch Routinen ausgeführt werden. Die beiden Routinen USB_Unload() und USB_PnPAddDevice() nehmen keinen Funktionscode in Anspruch werden aber auch vom I/O-Manager aufgerufen. USB_Create(): Die Funktion USB_Create() wird immer dann aufgerufen, wenn eine Anwendung im Usermode den Treiber mit der Win32 Funktion CreateFile() öffnet. Der I/O-Manager erzeugt dabei ein IRP mit dem Funktionscode IRP_MJ_CREATE. Dem Treiber wird dabei eine Datenstruktur FILE_OBJECT übergeben, die einen freien Speicherplatz enthält, auf dem der Treiber einen Zeiger auf eine private Datenstruktur speichern kann. Die so 77

78 Kapitel 8: Beispieltreiber gekennzeichnete FILE_OBJECT wird bei jedem weiteren Zugriff der Anwendung an den Treiber übergeben. Damit ist eine Identifizierung des geöffneten Gerätes möglich. USB_Close(): Die Funktion USB_Close() wird immer aufgerufen, wenn die Anwendung beendet wird, bzw. der Befehl CloseHandle() ausgeführt wird. Durch diese Funktion werden alle mit USB_Create() allokierten Ressourcen wieder freigegeben. USB_Unload(): Die Funktion USB_Unload() muss bei einem WDM Treiber vorhanden sein. Deren Aufgabe übernimmt aber bei einem PnP Treiber der Minor Funktionscode (IRP_MN_REMOVE_DEVICE). Minor Funktionscodes sind Untergruppen von Major Funktionscodes. USB_ProcessIOCTL(): Diese Funktion wird aufgerufen, wenn eine Usermode Anwendung den Befehl DeviceIoControl() ausführt. Diese Funktion wird später noch detaillierter Beschrieben. USB_Write und USB_Read(): Die Usermode Befehle WriteFile() bzw. ReadFile() rufen mit den Funktionscodes IRP_MJ_WRITE bzw. IRP_MJ_READ diese Funktionen auf. Die USB_Write() Funktion wird exemplarisch später erklärt. USB_ProcessSysConrolIrp(): Diese Funktion ist zwar vorhanden, wird aber in dieser Arbeit nicht unterstützt. Sie ist vorgesehen um das von Microsoft eingeführte Windows Management Interface (WMI) zu realisieren. Dies ist eine standardisierte Schnittstelle, die es ermöglicht Auswertungen über die Performance und Zuverlässigkeit des Gerätes durchzuführen. 78

79 Kapitel 8: Beispieltreiber USB_ProcessPnPIrp(): Die Funktion USB_ProcessPnPIrp() wird vom PnP Manager aufgerufen und unterstützt dazu folglich Plug&Play Aufgaben. In dieser Funktion werden verschiedene Minor Funktionscode des PnP Managers unterstützt: IRP_MN_START_DEVICE IRP_MN_QUERY_STOP_DEVICE IRP_MN_CANCEL_STOP_DEVICE IRP_MN_STOP_DEVICE IRP_MN_QUERY_REMOVE_DEVICE IRP_MN_CANCEL_REMOVE_DEVICE IRP_MN_SURPRISE_REMOVAL Hier ist auch die bei USB_Unload() erwähnte IRP_MN_REMOVE_DEVICE enthaltene Funktionscode enthalten, der die globalen Ressourcen wieder freigibt. USB_ProcessPowerIrp(): Dieser Funktion ist für das Power Management bestimmt. Es sind folgende Minor Funktionscodes implementiert: IRP_MN_WAIT_WAKE IRP_MN_SET_POWER IRP_MN_QUERY_POWER Der Minor Funktionscode IRP_MN_SET_POWER zum Beispiel kann das USB Gerät in verschiedene Betriebszustände versetzten. USB_PnPAddDevice(): Die USB_PnPAddDevice() Funktion wird gleich nach der DriverEntry() vom I/O-Manager aufgerufen. Die wichtigste Aufgabe der Funktion ist es ein Geräte Objekt mit IoCreateDevice() anzulegen. Mit IoAttachDeviceToDeviceStack() wird das Geräte Objekt in an oberster Position des Geräte Objekt Stacks gesetzt. Am Ende wird nochmals mit USB_KdPrint() eine Debug Information ausgegeben und ein StatusCode dem I/O-Manager zurückgeben. 79

80 Kapitel 8: Beispieltreiber 8.2 USB Deskriptor auslesen Das ausführen des Befehls DeviceIoControl(hDEV, IOCTL_USB_GET_CONFIG_DESCRIPTOR,,,,,, ) in der Usermode Anwendung veranlasst den I/O-Manager dazu ein IRP zu Erzeugen das den Funktionscode IRP_MJ_DEVICE_CONTROL besitzt. Außerdem wird in dem IRP der I/O Control Code (IOCTL) IOCTL_USB_GET_CONFIG_DESCRIPTOR eingetragen. Durch dem Major Funktionscode wird die Dispatch Funktion USB_ProcessIOCTL() ausgeführt. Die gesamte Funktion ist auf der nächsten Seite dargestellt. 80

81 Kapitel 8: Beispieltreiber NTSTATUS USB_ProcessIOCTL( IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp) { PIO_STACK_LOCATION irpstack; PVOID iobuffer; ULONG inputbufferlength; ULONG outputbufferlength; PDEVICE_EXTENSION deviceextension; ULONG iocontrolcode; NTSTATUS ntstatus; ULONG length; PUCHAR pch; PUSB_CONFIGURATION_DESCRIPTOR configurationdescriptor; USB_KdPrint( DBGLVL_DEFAULT,("Entering USB_ProcessIOCTL()\n")); } USB_IncrementIoCount(DeviceObject); deviceextension = DeviceObject->DeviceExtension; if (!USB_CanAcceptIoRequests(DeviceObject)) { ntstatus = STATUS_DELETE_PENDING; Irp->IoStatus.Status = ntstatus; Irp->IoStatus.Information = 0; IoCompleteRequest(Irp, IO_NO_INCREMENT ); USB_DecrementIoCount(DeviceObject); return ntstatus; } irpstack = IoGetCurrentIrpStackLocation(Irp); Irp->IoStatus.Status = STATUS_SUCCESS; Irp->IoStatus.Information = 0; iobuffer = Irp->AssociatedIrp.SystemBuffer; inputbufferlength = irpstack->parameters.deviceiocontrol.inputbufferlength; outputbufferlength = irpstack->parameters.deviceiocontrol.outputbufferlength; iocontrolcode = irpstack->parameters.deviceiocontrol.iocontrolcode; switch (iocontrolcode) { case IOCTL_USB_RESET_PIPE: USB_KdPrint( DBGLVL_DEFAULT,("Enter to IOCTL_USB_RESET_PIPE\n")); PUSBD_PIPE_INFORMATION pipe; PFILE_OBJECT fileobject; fileobject = irpstack->fileobject; pipe = (PUSBD_PIPE_INFORMATION) fileobject->fscontext; if(pipe == NULL) { ntstatus = Irp->IoStatus.Status = STATUS_INVALID_PARAMETER; } else { USB_ResetPipe(DeviceObject, pipe ); ntstatus = Irp->IoStatus.Status = STATUS_SUCCESS; } break; case IOCTL_USB_GET_CONFIG_DESCRIPTOR: USB_KdPrint( DBGLVL_DEFAULT,("Enter to IOCTL_USB_GET_CONFIG_DESCRIPTOR\n")); pch = (PUCHAR) iobuffer; configurationdescriptor = deviceextension->usbconfigurationdescriptor; if (configurationdescriptor) { length = configurationdescriptor->wtotallength; if (outputbufferlength >= length) { RtlCopyMemory(pch, (PUCHAR) configurationdescriptor, length); Irp->IoStatus.Information = length; ntstatus = Irp->IoStatus.Status = STATUS_SUCCESS; } else { Irp->IoStatus.Information = 0; ntstatus = Irp->IoStatus.Status = STATUS_INVALID_PARAMETER; } } else { Irp->IoStatus.Information = 0; ntstatus = Irp->IoStatus.Status = STATUS_DEVICE_DATA_ERROR; } break; case IOCTL_USB_RESET_DEVICE: USB_KdPrint( DBGLVL_DEFAULT,("Enter to IOCTL_USB_RESET_DEVICE\n")); ntstatus = USB_ResetDevice( DeviceObject ); break; case IOCTL_USB_TEST: USB_KdPrint( DBGLVL_DEFAULT,("Enter to IOCTL_USB_TEST\n")); break; default: USB_KdPrint( DBGLVL_DEFAULT,("Invalid IOCTL Parameter\n")); ntstatus = Irp->IoStatus.Status = STATUS_INVALID_PARAMETER; } // switch IoCompleteRequest (Irp, IO_NO_INCREMENT); USB_DecrementIoCount(DeviceObject); USB_KdPrint( DBGLVL_DEFAULT,("Exiting USB_ProcessIOCTL(%x)\n", ntstatus)); return ntstatus; 81

82 Kapitel 8: Beispieltreiber Die einzelnen Teilbereiche werden detaillierter beschrieben: USB_ProcessIOCTL( IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp) { PIO_STACK_LOCATION irpstack; PVOID iobuffer; ULONG inputbufferlength; ULONG outputbufferlength; PDEVICE_EXTENSION deviceextension; ULONG iocontrolcode; NTSTATUS ntstatus; ULONG length; PUCHAR pch; PUSB_CONFIGURATION_DESCRIPTOR configurationdescriptor; USB_KdPrint( DBGLVL_DEFAULT,("Entering USB_ProcessIOCTL()\n")); Der USB_ProcessIOCTL() Funktion werden die zwei Zeiger des Geräte Objekts und der IRP Struktur übergeben. Danach werden einige Variablen bzw. Strukturen deklariert und eine Debug Information ausgegeben. USB_IncrementIoCount(DeviceObject); deviceextension = DeviceObject->DeviceExtension; Als nächstes wird die USB_IncrementIoCount() Routine aufgerufen. Diese Routine erhöht einen Zähler (PendingIoCount). Bei jedem angeschlossenem Gerät oder Empfang eines IRP, wird dieser Zähler inkrementiert. Der Zähler gibt somit Aufschluss darüber wie viel IRP noch in Bearbeitung sind. Als nächstes wird die Geräteerweiterung im Geräte Objekt in einer Hilfsstruktur gespeichert. Dadurch wird der Code übersichtlicher. Der Umweg über das Geräte Objekt ist somit nicht mehr nötig. Dieses Vorgehen wird bei größeren Struktur Komponenten öfters verwendet. if (!USB_CanAcceptIoRequests(DeviceObject)) { ntstatus = STATUS_DELETE_PENDING; Irp->IoStatus.Status = ntstatus; Irp->IoStatus.Information = 0; IoCompleteRequest(Irp, IO_NO_INCREMENT ); USB_DecrementIoCount(DeviceObject); return ntstatus; } Die erste if Anweisung führt die Funktion USB_CanAcceptIoRequests() aus. Diese Funktion stellt den aktuellen Zustands des Gerätes fest. Die Funktion liefert den wert FALSE zurück, wenn das Gerät entfernt bzw. nicht gestartet wurde oder wenn IRPs in Bearbeitung sind die den Minor Funktionscode IRP_MN_QUERY_REMOVE_DEVICE bzw. IRP_MN_STOP_DEVICE haben. Wenn einer dieser Fehlerbedingungen erfühlt ist, werden 82

83 Kapitel 8: Beispieltreiber einige Status Informationen gesetzt und die USB_ProcessIOCTL() mit dem Status Code STATUS_DELETE_PENDING beendet. irpstack = IoGetCurrentIrpStackLocation (Irp); Irp->IoStatus.Status = STATUS_SUCCESS; Irp->IoStatus.Information = 0; Im normalen Fall wird aber die Funktion weiter abgearbeitet. Es wird der zu diesem Treiber gehörende IRP Stapel aus dem IRP mit der Betriebssystemfunktion IoGetCurrentIrpStackLocation() einer Struktur zugewiesen. Außerdem werden die ersten erfolgreichen Status Informationen zugewiesen, die aber später durchaus wieder überschrieben werden können. iobuffer = Irp->AssociatedIrp.SystemBuffer; inputbufferlength = irpstack->parameters.deviceiocontrol.inputbufferlength; outputbufferlength = irpstack->parameters.deviceiocontrol.outputbufferlength; iocontrolcode = irpstack->parameters.deviceiocontrol.iocontrolcode; Wie bei der Geräteerweiterung zuvor auch, werden in den nächsten vier Zeilen, Struktur Komponenten in Hilfsvariablen gespeichert. Die beiden wichtigen Variablen sind hier iobuffer und iocontrolcode. iobuffer zeigt auf den Systemspeicher, den der I/O-Manager für die Übertragung der DeviceIoControl() Funktion allokiert hat. iocontolcode enthält den dazugehörigen IOCTL. switch (iocontrolcode) { case IOCTL_USB_GET_CONFIG_DESCRIPTOR: USB_KdPrint( DBGLVL_DEFAULT,("Enter to IOCTL_USB_GET_CONFIG_DESCRIPTOR\n")); pch = (PUCHAR) iobuffer; configurationdescriptor = deviceextension->usbconfigurationdescriptor; Mit der switch Anweisung wird der jeweilige IOCTL verteilt. In unserem Beispiel soll hier nur der Bereich erklärt werden, der für IOCTL_USB_GET_CONFIG_DESCRIPTOR zuständig ist. Zuerst wird eine Information an DebugView ausgegeben, ob man auch in der richtigen Verzweigung gelandet ist. Danach wird der Zeiger auf dem Systemspeicher der pch Variable zugewiesen. Zuletzt wird der Zeiger auf den Deskriptor, der bei der Initialisierung des USB Gerätes vom USBD ermittelt wurde, einer Hilfsstruktur übergeben. 83

84 Kapitel 8: Beispieltreiber if (configurationdescriptor) { length = configurationdescriptor->wtotallength; if (outputbufferlength >= length) { RtlCopyMemory(pch, (PUCHAR) configurationdescriptor, length); Irp->IoStatus.Information = length; ntstatus = Irp->IoStatus.Status = STATUS_SUCCESS; } else { Irp->IoStatus.Information = 0; ntstatus = Irp->IoStatus.Status = STATUS_INVALID_PARAMETER; } } else { Irp->IoStatus.Information = 0; ntstatus = Irp->IoStatus.Status = STATUS_DEVICE_DATA_ERROR; } Die if Anweisung prüft, ob diese Deskriptor Struktur nicht leer ist. Falls sie jedoch leer ist, liefert die Funktion den Status Code STATUS_DEVICE_DATA_ERROR zurück. Ist diese Struktur mit Werten belegt, wird zuerst die Länge des Deskriptors ermittelt. Die darauf folgende if Anweisung vergleicht diese Länge des Deskriptors mit der Länge, die tatsächlich für den Datentransfer allokiert wurde. Überschreitet die Deskriptor Länge den Speicherbereich, wird der STATUS_INVALID_PARAMETER dem I/O-Manager übergeben. Ist allerdings alles in Ordnung, wird der Deskriptor mit Hilfe der RtlCopyMemory() Funktion vom Systempuffer in den Anwendungspuffer kopiert (BIO). Anschließend wird die Länge des Deskriptors in die IRP Struktur eingetragen und der Status Code auf STATUS_SUCCESS gesetzt. } IoCompleteRequest (Irp, IO_NO_INCREMENT); USB_DecrementIoCount(DeviceObject); USB_KdPrint( DBGLVL_DEFAULT,("Exiting USB_ProcessIOCTL(%x)\n", ntstatus)); return ntstatus; Dem I/O-Manager wird mit IoCompleteRequest() mitgeteilt, das das IRP komplett abgearbeitet wurde. Der am Anfang der Funktion um eins erhöhte Zähler (PendingIoCount) wird mit USB_DecrementIoCount() wieder um eins erniedrigt. Zum Abschluss wird nochmals eine Debug Information mit dem aktuellen Status Code ausgegeben und an den I/O-Manager übergeben. 8.3 Daten an das USB Gerät senden Um Daten von Usermode Anwendung auf das USB Gerät zu übertragen, ist die API Funktion WriteFile() zuständig. Der I/O-Manager erzeugt dazu ein IRP, das den Funktionscode IRP_MJ_WRITE besitzt. Durch dem Major Funktionscode wird die Dispatch 84

85 Kapitel 8: Beispieltreiber Funktion USB_Write() ausgeführt. Diese Funktion führt eine Reihe weiterer Funktionen aus. Abbildung 8.1: Ablauf eines Schreib Prozesses Jede einzelne Funktion ist für einen Teilbereich zuständig: USB_Write(): Die USB_Write() Dispatch Funktion ruft nur die nächste Funktion auf. USB_StagedReadWrite(): Diese Funktion wird von USB_Read() bzw. USB_Write() gleichermaßen aufgerufen. Zur Unterscheidung dient eine boolsche Variable. Diese Funktion teilt die zu übertragenen Daten wenn nötig in kleinere Pakete. Diese Paket Größe hängt von dem jeweiligen Pipe Typ und der PaketSize ab. 85

86 Kapitel 8: Beispieltreiber USB_CanAcceptIoRequest(): Diese Funktion wurde auch schon beim auslesen des Deskriptors benutzt. Sie stellt wiederum den aktuellen Zustands des Gerätes fest. USB_CanAcceptIoRequest() überprüft, ob das USB Gerät entfernt bzw. nicht gestartet wurde oder wenn IRPs in Bearbeitung sind die den Minor Funktionscode IRP_MN_QUERY_REMOVE_DEVICE bzw. IRP_MN_STOP_DEVICE haben. USB_SingleUrbReadWrite(): USB_SingleUrbReadWrite() liest aus dem File Objekt die Pipe Nummer aus, welche als Übertragungskanal dienen soll. Anschließend koordiniert sie über weitere Hilfsfunktionen die Verarbeitung des IRPs. Hier zählt auch das anhängen des URBs an das IRP. USB_BuildAsyncRequest(): Mit dieser Funktion wird die URB Struktur aufgebaut. Die Werte der einzelnen Komponenten wie die MdlAddress, PipeHandle oder TransferFlags werden in die Struktur eingetragen. USB_IncrementIoCount(): Die USB_IncrementIoCount() Funktion ist auch schon von dem vorherigen Kapitel bekannt, sie erhöht den Zähler (PendingIoCount). IoCallDriver(): Mit dieser Betriebssystemfunktion wird das modifizierte IRP, das das URB enthält, der nächst niedrigeren Treiber Schicht also USBD übergeben. USB_SimpleReadWrite_Complete(): Die Funktion gibt belegte Ressourcen wieder frei und belegt diverse Informationsregister im Geräte Objekt mit Status Werten. USB_DecrementIoCount(): Diese von USB_SimpleReadWrite_Complete() aufgerufene Funktion erniedrigt den mit USB_IncrementIoCount() erhöhten Zähler wieder. 86

87 Kapitel 9: Usermode Anwendung 9. Usermode Anwendung Die Usermode Anwendung stellt nur eine kleine Konsolenanwendung dar. Mit Hilfe verschiedener Übergabe Argumente lassen sich alle Funktionen des Treibers testen. Die Argumente lassen sich beliebig in ihrer Funktion erweitern. Abbildung 9.1: Usermode Anwendung In dieser Usermode Anwendung werden die verschiedene API Aufrufe wie ReadFile(), WriteFile(), DeviceIoControl(), CreateFile() oder CloseFile() dazu benützt um Zugriff auf die Dispatch Funktionen des Treibers zu haben. Zum Beispiel wird mit dem w Parameter die Funktion WriteFile() aufgerufen und es kann eine bestimmte Anzahl an Bytes an das USB Gerät gesendet werden. Der u Parameter benützt dagegen die DeviceIoControl() Funktion mit dem IOCTL_USB_GET_CONFIG_DESCRIPTOR IOCTL. 87