In der Computerwissenschaft, einem Gerät-Fahrer oder dem Softwarefahrer ist ein Computerprogramm, das Computerprogramme des höheren Niveaus erlaubt, mit einem Hardware-Gerät aufeinander zu wirken.

Ein Fahrer kommuniziert normalerweise mit dem Gerät durch den Computerbus oder das Kommunikationssubsystem, zu dem die Hardware in Verbindung steht. Wenn ein Benennen-Programm eine Routine im Fahrer, den Fahrer-Problem-Befehlen zum Gerät anruft. Sobald das Gerät Daten dem Fahrer zurücksendet, kann der Fahrer Routinen im ursprünglichen rufenden Programm anrufen. Fahrer sind von der Hardware abhängiges und "spezifisches Betriebssystem". Sie stellen gewöhnlich die für jede notwendige asynchrone zeitabhängige Hardware-Schnittstelle erforderliche Unterbrechungsbehandlung zur Verfügung.

Zweck

Ein Gerät-Fahrer vereinfacht Programmierung, indem er als Übersetzer zwischen einem Hardware-Gerät und den Anwendungen oder Betriebssystemen handelt, die sie verwenden. Programmierer können den Anwendungscode des höheren Niveaus unabhängig von beliebiger spezifischer Hardware schreiben, die der Endbenutzer verwendet. Physische Schichten kommunizieren mit spezifischen Gerät-Beispielen. Zum Beispiel muss ein Serienhafen Standardnachrichtenprotokolle wie XON/XOFF behandeln, die für die ganze Serienhafen-Hardware üblich sind. Das würde durch einen Serienhafen logische Schicht geführt. Jedoch muss die physische Schicht mit einem besonderen Serienhafen-Span kommunizieren. 16550 UART Hardware unterscheidet sich von PL-011. Die physische Schicht richtet diese mit dem Span spezifischen Schwankungen. Herkömmlich gehen OS Bitten zur logischen Schicht zuerst. Der Reihe nach besucht die logische Schicht die physische Schicht, OS-Bitten in durch die Hardware verständlichen Begriffen durchzuführen. Umgekehrt, wenn ein Hardware-Gerät auf den OS antworten muss, verwendet es die physische Schicht, um mit der logischen Schicht zu sprechen.

In Linux Umgebungen können Programmierer Gerät-Treiber entweder als Teile des Kerns oder getrennt als loadable Module bauen. Makedev schließt eine Liste der Geräte in Linux ein: TtyS (Terminal), LP (paralleler Hafen), hd (Platte), Schleife (Echoprüfungsplattengerät), Ton (schließen diese Mixer, Ablaufsteuerung, dsp, und Audio-ein)...

Windows von Microsoft.sys Dateien und Module von Linux.ko enthält loadable Gerät-Treiber. Der Vorteil von loadable Gerät-Fahrern besteht darin, dass sie, nur wenn notwendig, geladen und dann ausgeladen werden können, so Kerngedächtnis sparend.

Entwicklung

Das Schreiben eines Gerät-Fahrers verlangt ein eingehendes Verstehen dessen, wie die Hardware und die Software einer gegebenen Plattform fungieren. Fahrer funktionieren in einer hoch privilegierten Umgebung und können Katastrophe verursachen, wenn sie Dinge falsch verstehen. Im Gegensatz kann der grösste Teil der Benutzerniveau-Software auf modernen Betriebssystemen angehalten werden, ohne den Rest des Systems außerordentlich zu betreffen. Sogar Fahrer, die in der Benutzerweise durchführen, können ein System zertrümmern, wenn das Gerät falsch programmiert wird. Diese Faktoren machen es schwieriger und gefährlich, um Probleme zu diagnostizieren.

So fällt die Aufgabe, Fahrern zu schreiben, gewöhnlich Softwareingenieuren, die für Gesellschaften der Hardware-Entwicklung arbeiten. Das ist, weil sie bessere Information haben als die meisten Außenseiter über das Design ihrer Hardware. Außerdem wurde es im Hardware-Hersteller-Interesse traditionell betrachtet zu versichern, dass ihre Kunden ihre Hardware auf eine optimale Weise verwenden können. Gewöhnlich wird der Fahrer des logischen Geräts (LDD) vom Betriebssystemverkäufer geschrieben, während der Fahrer des realen Gerätes (PDD) vom Gerät-Verkäufer durchgeführt wird. Aber in den letzten Jahren haben Nichtverkäufer zahlreichen Gerät-Fahrern, hauptsächlich für den Gebrauch mit der freien und offenen Quelle Betriebssysteme geschrieben. In solchen Fällen ist es wichtig, dass der Hardware-Hersteller Auskunft darüber gibt, wie das Gerät kommuniziert. Obwohl diese Information stattdessen durch die Rücktechnik erfahren werden kann, ist das mit der Hardware viel schwieriger, als es mit der Software ist.

Microsoft hat versucht, Systeminstabilität wegen schlecht geschriebener Gerät-Treiber durch das Schaffen eines neuen Fachwerks für die Fahrer-Entwicklung, genannt Windows Driver Foundation (WDF) zu reduzieren. Das schließt User-Mode Driver Framework (UMDF) ein, das Entwicklung von bestimmten Typen von Fahrern — in erster Linie diejenigen fördert, die ein nachrichtenbasiertes Protokoll durchführen, um mit ihren Geräten — als Benutzerweise-Fahrer zu kommunizieren. Wenn solche Fahrer schlecht funktionieren, verursachen sie Systeminstabilität nicht. Das Modell von Kernel-Mode Driver Framework (KMDF) setzt fort, Entwicklung von Kernweise-Gerät-Fahrern zu erlauben, aber versucht, Standarddurchführungen von Funktionen zur Verfügung zu stellen, die weithin bekannt sind, Probleme, einschließlich der Annullierung von Eingabe/Ausgabe-Operationen, Macht-Management, und Stecker und Spiel-Gerät-Unterstützung zu verursachen.

Apfel hat ein Fachwerk der offenen Quelle, um sich zu entwickeln, Fahrer auf Mac OS X haben den Eingabe/Ausgabe-Bastelsatz genannt.

Kernweise gegen die Benutzerweise

Gerät-Fahrer, besonders auf Windows-Plattformen von Microsoft, können in der Kernweise laufen (Klingeln Sie 0 auf x86 Zentraleinheiten), oder in der Benutzerweise (Klingeln 3 auf x86 Zentraleinheiten). Der primäre Vorteil, einen Fahrer in der Benutzerweise zu führen, ist verbesserte Stabilität, da ein schlecht geschriebener Benutzerweise-Gerät-Treiber das System durch das Überschreiben des Kerngedächtnisses nicht zertrümmern kann. Andererseits, user/kernel-mode Übergänge erlegen gewöhnlich eine beträchtliche Leistung oben auf, dadurch Benutzerweise-Treiber für die niedrige Latenz und hohen Durchfluss-Voraussetzungen verbietend.

Auf

Kernraum kann durch das Benutzermodul nur durch den Gebrauch von Systemanrufen zugegriffen werden.

Endbenutzer-Programme wie die UNIX-Schale oder gestützte Anwendungen anderen GUI sind ein Teil des Benutzerraums. Diese Anwendungen wirken mit Hardware durch unterstützte Funktionen des Kerns aufeinander.

Anwendungen

Wegen der Ungleichheit der Hardware und Betriebssysteme funktionieren Fahrer in vielen verschiedenen Umgebungen. Fahrer können verbinden mit:

• Drucker
• Videoadapter
• Netzkarten
• gesunde Karten
• lokale Busse von verschiedenen Sorten — insbesondere für den Bus, der auf modernen Systemen meistert
• Eingabe/Ausgabe-Busse der niedrigen Bandbreite von verschiedenen Sorten (um Geräte wie Mäuse, Tastaturen, USB usw. anzuspitzen)

,

• Computerspeichergeräte wie Festplatte, CD-ROM und Diskette-Busse (ATA, SATA, SCSI)
• das Einführen der Unterstützung für verschiedene Dateisysteme
• Bildscanner
• Digitalkameras

Allgemeine Niveaus der Abstraktion für Gerät-Fahrer schließen ein:

• für die Hardware:
• das Verbinden direkt
• das Schreiben zu oder das Lesen von einer Gerät-Kontrolle schreiben ein
• das Verwenden einer Schnittstelle des höheren Niveaus (z.B Video-BIOS)
• das Verwenden eines anderen Gerät-Fahrers der niedrigeren Ebene (z.B Dateisystemfahrer, die Plattenfahrer verwenden)
• das Simulieren der Arbeit mit der Hardware, während man etwas völlig verschiedener tut
• für die Software:
• das Erlauben des Betriebssystems direkter Zugang zu Hardware-Mitteln
• das Einführen von nur Primitiven
• das Einführen einer Schnittstelle für die Nichtfahrer-Software (z.B Twain)
• das Einführen einer Sprache, manchmal ziemlich auf höchster Ebene (z.B PostScript)

Die Auswahl und die Installation der richtigen Gerät-Fahrer für die gegebene Hardware sind häufig ein Schlüsselbestandteil der Computeranlagenkonfiguration.

Fahrer des virtuellen Geräts

Fahrer des virtuellen Geräts vertreten eine besondere Variante von Gerät-Fahrern. Sie werden verwendet, um mit einem Hardware-Gerät besonders in Virtualisierungsumgebungen zum Beispiel wettzueifern, wenn ein DOS-Programm auf einem Windows-Computer von Microsoft geführt wird, oder wenn ein Gast Betriebssystem auf, zum Beispiel, ein Gastgeber von Xen geführt wird. Anstatt dem Gast Betriebssystem zum Dialog mit der Hardware zu ermöglichen, nehmen Fahrer des virtuellen Geräts die entgegengesetzte Rolle und eifern mit einem Stück der Hardware wett, so dass der Gast Betriebssystem und seine Fahrer, die innerhalb einer virtuellen Maschine laufen, das Trugbild haben kann, auf echte Hardware zuzugreifen. Versuche durch den Gast Betriebssystem, um auf die Hardware zuzugreifen, werden zum Fahrer des virtuellen Geräts im Gastgeber Betriebssystem als z.B Funktionsanrufe aufgewühlt. Der Fahrer des virtuellen Geräts kann auch vorgetäuschte Ereignisse des Verarbeiter-Niveaus wie Unterbrechungen in die virtuelle Maschine senden.

Virtuelle Geräte können auch in einer non-virtualized Umgebung funktionieren. Zum Beispiel wird ein virtueller Netzadapter mit einem virtuellen privaten Netz verwendet, während ein virtuelles Plattengerät mit iSCSI verwendet wird.

Das beste Beispiel für Fahrer des virtuellen Geräts kann "Dämon-Werkzeuge" sein

Es gibt mehrere Varianten von Fahrern des virtuellen Geräts.

Offene Fahrer

• Drucker: TASSEN
• ÜBERFÄLLE: CCISS (Befehl-Schnittstelle von Compaq für die SCSI-3-Unterstützung)
• Scanner: GEISTIG GESUNDER
• Video: Vidix, direkte Übergabe-Infrastruktur

Beschreibungen von Solaris allgemein verwendeter Gerät-Treiber

• frei Kai: Schneller/breiter SCSI Kontrolleur
• hme: Schnell (10/100 Mbit/s) Ethernet
• isp: SCSI Differenzialkontrolleure und die Karte von SunSwift
• glm: (Gigabaud Verbindungsmodul) Kontrolleure von UltraSCSI
• scsi: Geräte von Small Computer Serial Interface (SCSI)
• sf: soc + oder soziale Fiber Channel Arbitrated Loop (FCAL)
• soc: Kontrolleure von SPARC Storage Array (SSA)
• sozial: Optische Serienkontrolleure für FCAL (soc +)

APIs

• Windows Display Driver Model (WDDM) - der grafische Anzeigefahrer Architektur für die Windows-Aussicht
• Windows Driver Foundation (WDF)
• Windows Driver Model (WDM)
• Network Driver Interface Specification (NDIS) - ein Standardnetzkarte-Fahrer API
• Advanced Linux Sound Architecture (ALSA) - der normale gesunde Fahrer von Linux Schnittstelle
• Scanner Access Now Easy (SANE) - eine Schnittstelle des öffentlichen Gebiets zur Rasterimage-Scanner-Hardware
• Eingabe/Ausgabe-Bastelsatz - ein Fachwerk der offenen Quelle vom Apfel, um Gerät-Fahrer von Mac OS X zu entwickeln
• Installable File System (IFS) - eine filesystem API für IBM OS/2 und Microsoft Windows NT
• Offene Datenverbindungsschnittstelle (ODI) - eine Netzkarte-API, die NDIS ähnlich

ist

• Uniform Driver Interface (UDI) - ein Quer-Plattform-Fahrer Schnittstelle plant
• Dynax Fahrer Framework (dxd) - C ++ öffnen Quellquer-Plattform-Treiber Fachwerk für KMDF und IOKit

Bezeichner

Ein Gerät auf dem PCI oder USB-Bus wird durch zwei Personalausweis identifiziert, die aus 4 Zahlen und/oder Briefen A an F bestehen. Der Verkäufer-Personalausweis erkennt den Verkäufer des Geräts. Der Gerät-Personalausweis identifiziert ein spezifisches Gerät von diesem Hersteller/Verkäufer.

Ein PCI Gerät hat häufig ein ID-Paar für den Hauptspan des Geräts und auch ein Subsystem-ID-Paar, das den Verkäufer erkennt, der vom Span-Hersteller verschieden sein kann.

Siehe auch

• Klassenfahrer
• Gerät-Fahrer Synthese und Überprüfung
• Firmware
• Unterbrechung
• Kernmodul von Loadable
• Makedev
• Hardware der offenen Quelle
• Drucker-Fahrer
• udev

Links

• Windows-Hardware-Entwickler von Microsoft zentraler
• Linux Hardware-Vereinbarkeitslisten und Linux Fahrer
• Schreibende Gerät-Fahrer für den Digitalen UNIX Betriebssystem: Ein Tutorenkurs
• Das Verstehen moderner Gerät-Fahrer (Linux)