Freigeben über

Unterschiede zwischen WDM und WDF

Das WDM-Modell ist eng mit dem Betriebssystem verbunden. Treiber interagieren direkt mit dem Betriebssystem, indem sie Systemdienstroutinen aufrufen und Betriebssystemstrukturen bearbeiten. Da WDM-Treiber vertrauenswürdige Kernelmoduskomponenten sind, bietet das System eingeschränkte Überprüfungen der Treibereingaben.

Im Vergleich dazu konzentriert sich das WDF-Modell (Windows Driver Frameworks) auf die Anforderungen des Treibers, und die Frameworkbibliothek verarbeitet den Großteil der Interaktionen mit dem System.

Das Framework fängt E/A-Anforderungen ab, führt bei Bedarf Standardaktionen aus und ruft die Rückrufe des Treibers nach Bedarf auf. Das WDF-Modell ist objektbasiert und ereignisgesteuert. Objekte stellen allgemeine Treiberkonstrukte dar, z. B. ein Gerät, eine Sperre oder eine Warteschlange. Ein Kernel-Mode Driver Framework (KMDF) oder User-Mode Driver Framework (UMDF)-Treiber enthält einen Einstiegspunkt (DriverEntry), die ereignisbezogenen Rückruffunktionen, die erforderlich sind, um das Gerät zu warten und E/A zu unterstützen, sowie alle zusätzlichen internen Hilfsfunktionen, von denen die Implementierung abhängt.

In diesem Abschnitt werden wichtige Unterschiede zwischen WDM und WDF in den folgenden Bereichen beschrieben:

Treiberstruktur

Sowohl WDM- als auch WDF-Treiber enthalten eine DriverEntry-Routine , eine Reihe von Routinen, die aufgerufen werden, um bestimmte E/A-Anforderungen zu verarbeiten, und verschiedene Supportroutinen.

In einem WDM-Treiber werden die E/A-Dispatchroutinen bestimmten wichtigen IRP-Codes zugeordnet. Die Dispatchroutinen empfangen IRPs vom E/A-Manager, analysieren sie und reagieren entsprechend.

In einem WDF-Treiber registriert das Framework seine eigenen Dispatchroutinen, die IRPs vom E/A-Manager empfangen, diese analysieren und dann die Ereignisrückruffunktionen des Treibers aufrufen, um sie zu verarbeiten. Die Ereignisrückruffunktionen führen in der Regel eine spezifischere Aufgabe aus als die allgemeinen E/A-Dispatchroutinen des WDM-Treibers.

Ein typischer WDF-Treiber für ein Plug & Play-Gerät enthält Folgendes:

  • Eine DriverEntry-Routine .
  • Eine EvtDriverDeviceAdd-Routine , die in ihrer Funktion einer WDM-AddDevice-Routine ähnelt.
  • Mindestens eine E/A-Warteschlange.
  • Eine oder mehrere E/A-Ereignisrückruffunktionen, die in ihrer Funktion den E/A DispatchXxx-Routinen eines WDM-Treibers ähneln.
  • Rückrufe zur Behandlung der vom Treiber unterstützten Plug & Play- und Energieereignisse.
  • Rückrufe, um die vom Treiber unterstützten WMI-Anforderungen zu verarbeiten. (nur KMDF)
  • Je nach Bedarf zusätzliche Rückrufe für Objektbereinigung, Dateierstellung und E/A-Ziele usw.

Geräteobjekte und Treiberrollen

Sowohl WDM- als auch WDF-Treiber erstellen ein oder mehrere Geräteobjekte. Jedes Geräteobjekt stellt eine Treiberrolle dar, die das Ziel von E/A-Anforderungen ist. Ein Objekt des physischen Geräts (PDO) stellt einen Bustreiber, ein Funktionales Geräteobjekt (FDO) einen Funktionstreiber und ein Filtergeräteobjekt (Filter-DO) einen Filtertreiber dar.

In WDM-Treibern sind diese Treiberrollen implizit, sodass der Treiber nachverfolgen muss, welche Rolle jedes Geräteobjekt darstellt und entsprechend auf IRPs reagieren muss.

WDF-Treiber geben jedoch explizit an, ob ein Geräteobjekt eine PDO (nur KMDF), FDO oder filtert DO und registrieren Ereignisrückrufe, die für diese Rolle spezifisch sind. Beispielsweise sind PDOs das Ziel von Ressourcenanforderungenabfragen und Geräteauswurfanforderungen, während FDOs und Filter-DOs solche Anforderungen nicht verarbeiten.

Ein WDF-Treiber konfiguriert jedes Geräteobjekt so, dass bestimmte E/A-Anforderungen empfangen werden. Das Framework ruft den Treiber auf, um nur diese E/A-Anforderungen zu verarbeiten, und führt eine Standardaktion für alle anderen Anforderungen aus. Wenn das Geräteobjekt einen Filtertreiber darstellt, übergibt das Framework alle anderen Anforderungen an den nächstniedreren Treiber. Wenn das Geräteobjekt einen Bus- oder Funktionstreiber darstellt, schlägt das Framework alle anderen Anforderungstypen fehl.

Für Plug & Play- und Energieanforderungen ruft das Framework den KMDF- oder UMDF-Treiber nur für die Anforderungen auf, die für jedes Geräteobjekt geeignet sind – und zwar zum geeigneten Zeitpunkt. Beispielsweise muss eine FDO auf bestimmte Anforderungen reagieren, nachdem die zugrunde liegende PDO bereits geantwortet hat. In einem WDM-Treiber muss die FDO eine E/A-Vervollständigungsroutine festlegen, den IRP im Stapel übergeben und nach niedrigeren Treibern verarbeiten. Ein WDF-Treiber implementiert einfach die entsprechende Rückrufroutine, und das Framework ruft sie auf, nachdem die Verarbeitung niedrigerer Treiber abgeschlossen ist.

Informationen zum Erstellen von Framework-Geräteobjekten finden Sie unter Erstellen eines Framework-Geräteobjekts.

Einige Treiber verarbeiten auch bestimmte E/A-Anforderungen, die unabhängig von Plug & Play sind. Ein WDM-Treiber erstellt eine DEVICE_OBJECT als Ziel für solche Anforderungen, fügt ihn jedoch nicht an den Plug & Play Gerätestapel an. Um das gleiche Ergebnis zu erzielen, erstellt ein KMDF-Treiber ein Steuerelementgerätobjekt. Einige frameworkbasierte Treiber verwenden Steuerungsgeräteobjekte, um "Sideband"-E/A-Mechanismen zu implementieren, sodass sie bestimmte Typen von E/A-Anforderungen unabhängig vom Gerätestatus empfangen können.

Objektmodell

WDF unterstützt ein kohärentes Objektmodell, bei dem Objekte für Treiber undurchsichtig sind, vom Treiber konfigurierbare Kontextbereiche bereitstellen und von einem Handle referenziert werden. WDM-Objekte sind systemweite Objekte, auf die Treiber zugreifen können und auf die durch Zeiger verwiesen wird. Ein Treiber, der ein WDM-Objekt beschädigt, kann das gesamte System beschädigen. Das Beschädigen eines WDF-Objekts ist nicht nur schwieriger, da das Framework die vom Treiber bereitgestellten Daten überprüft, sondern auch viel seltener zu systemweiten Problemen führt.

Informationen zur Benennungskonvention für KMDF-Objekte finden Sie unter WDF-Architektur.

Das Framework verwaltet eine Verweisanzahl für jedes Objekt, wodurch eine gewisse Kontrolle über seine Lebensdauer ermöglicht wird. Weitere Informationen finden Sie unter Framework Object Life Cycle.

Obwohl viele der WDF-Objekte WDM-Objekten entsprechen, unterstützen die WDF-Objekte Features, die zusätzlichen Code in einem WDM-Treiber erfordern. Alle WDF-Objekte unterstützen treiberdefinierbare Objektkontextbereiche, sodass ein Treiber Informationen speichern kann, die sich auf eine bestimmte Instanz eines Objekts beziehen, mit dem Objekt selbst. Objekte verfolgen in der Regel auch den Zustand. Beispielsweise sind WDFQUEUE-Objekte mehr als nur eine Liste von E/A-Anforderungen. sie unterstützen verschiedene Arten von Verteiler, automatische Synchronisierung mit Plug & Play und Anforderungsabbruch. Bei WDFMEMORY-Objekten trägt die vom Framework verwaltete Verweisanzahl dazu bei, Speicherverluste und vorzeitige Freigabe von Ressourcen zu verhindern.

Objekterstellung

WDF-Treiber folgen einem regulären Muster, um alle Objekttypen zu erstellen:

  1. Initialisieren Sie die Konfigurationsstruktur für das -Objekt, sofern vorhanden.
  2. Initialisieren Sie optional die Attributstruktur für das -Objekt.
  3. Rufen Sie die Erstellungsmethode auf, um das -Objekt zu erstellen.

Die Konfigurationsstruktur und die Attributstruktur liefern grundlegende Informationen zum Objekt und zur Verwendung durch den Treiber. Alle Objekttypen verwenden WDF_OBJECT_ATTRIBUTES als Attributstruktur, aber die Konfigurationsstruktur für jeden Objekttyp ist unterschiedlich, und einige Objekte weisen keines auf. Es gibt beispielsweise eine WDF_DRIVER_CONFIG-Struktur , aber keine WDF_DEVICE_CONFIG-Struktur .

Die Konfigurationsstruktur enthält Zeiger auf objektspezifische Informationen, z. B. die Ereignisrückruffunktionen des Treibers für das Objekt. Der Treiber füllt diese Struktur aus und übergibt sie dann an das Framework, wenn die Objekterstellungsmethode aufgerufen wird. Beispielsweise enthält ein Aufruf von WdfDriverCreate einen Zeiger auf eine WDF_DRIVER_CONFIG-Struktur , die einen Zeiger auf die EvtDriverDeviceAdd-Rückruffunktion des Treibers enthält.

Das Framework definiert Funktionen mit dem Namen WDF_Object_CONFIG_INIT, um die Konfigurationsstrukturen zu initialisieren, wobei Object den Namen des Objekttyps darstellt. Die WDF_OBJECT_ATTRIBUTES_INIT-Funktion initialisiert die WDF_OBJECT_ATTRIBUTES-Struktur eines Treibers.

Objektkontextbereich

Jede Instanz eines Objekts kann über einen oder mehrere Objektkontextbereiche verfügen. Der Objektkontextbereich ist ein Speicherbereich für Daten, die sich auf diese bestimmte Instanz beziehen, z. B. ein vom Treiber zugeordnetes Ereignisobjekt. Der Treiber bestimmt die Größe und das Layout des Objektkontextbereichs. Für ein Geräteobjekt entspricht der Objektkontextbereich der WDM-Geräteerweiterung. Informationen zum Definieren und Initialisieren eines Kontextbereichs finden Sie unter Framework Object Context Space.

Unterstützte IRP-Typen

WDF unterstützt eine Teilmenge der Windows-IRPs. Eine Zusammenfassung der wichtigsten WDM-IRP-Typen und der entsprechenden WDF-Ereignisrückruffunktionen finden Sie unter WDM IRPs und WDF-Ereignisrückruffunktionen.

Auch wenn Ihr Treiber irPs empfängt, die nicht in der Tabelle aufgeführt sind, können Sie ihn zu KMDF portieren. KMDF bietet einen Mechanismus, über den ein Treiber "unformatierte" WDM-IRPs empfangen kann, aber auch die KMDF-Features für andere IRPs-Typen verwenden kann. Weitere Informationen finden Sie unter Behandeln von WDM-IRPs außerhalb des Frameworks.

E/A-Warteschlangen

Fast alle Treiber stellen E/A-Anforderungen in die Warteschlange. WDM-Treiber verwenden in der Regel einen der folgenden Ansätze:

  • Implementieren Sie eine StartIo-Funktion , und rufen Sie IoStartPacket und IoStartNextPacket auf, um die Gerätewarteschlange des Systems für E/A-Anforderungen zu verwenden.
  • Verwenden Sie ioCsqXxx oder andere Listenverwaltungsfunktionen, um eigene interne E/A-Warteschlangen zu implementieren.
  • Verwenden Sie die KeXxxDeviceQueue-Funktionen , um eine Warteschlange zu initialisieren und zu verwalten, die durch eine Drehsperre geschützt ist.

Ein WDF-Treiber erstellt ein WDF-Warteschlangenobjekt (WDFQUEUE), um eine E/A-Warteschlange darzustellen. Das WDF-Warteschlangenobjekt ähnelt einer abbruchsicheren Warteschlange, bietet jedoch zusätzliche Features.

Wenn Sie einen WDM-Treiber auf WDF portieren, können Sie den WDF-Warteschlangenmechanismus unabhängig vom Mechanismus verwenden, den der WDM-Treiber verwendet. Weitere Informationen zu Warteschlangen finden Sie unter Framework-Warteschlangenobjekte.

Synchronisierung und Parallelität

WDF-Treiber profitieren von einer integrierten Synchronisierungsunterstützung, die für WDM-Treiber nicht verfügbar ist. Obwohl diese Unterstützung nicht bedeutet, dass der Treiber Parallelität und synchronen Zugriff auf Daten ignorieren kann, erfordern WDF-Treiber dennoch deutlich weniger Sperren und weniger Synchronisierungscode als WDM-Treiber.

Weitere Informationen zu den Synchronisierungsfeatures, die das Framework bereitstellt, finden Sie unter Synchronisierungstechniken.

Treiberinstallation

Wie WDM-Treiber werden KMDF- und UMDF-Treiber mithilfe von INF-Dateien installiert. Für die Installation des WDF-Treibers ist jedoch manchmal ein Framework-Co-Installer erforderlich, das mit dem Windows Driver Kit (WDK) bereitgestellt wird. Das Co-Installationsprogramm stellt sicher, dass eine kompatible Version der Frameworkbibliothek auf dem Zielsystem vorhanden ist. Informationen zur Installation finden Sie unter Erstellen und Laden eines WDF-Treibers.