Freigeben über

KMDF als generisches Treiberpaarmodell

In diesem Artikel wird die Idee erläutert, dass das Kernel-Mode Driver Framework (KMDF) als generisches Treiberpaarmodell angesehen werden kann.

Anmerkung

Bevor Sie dieses Thema lesen, sollten Sie die Ideen in Minitreiber und Treiberpaaren verstehen.

Im Laufe der Jahre hat Microsoft mehrere technologiespezifische Treibermodelle erstellt, die dieses Paradigma verwenden:

  • Der Treiber ist in zwei Teile unterteilt: einen, der für die allgemeine Verarbeitung zuständig ist, und einen, der die spezifische Verarbeitung eines bestimmten Geräts übernimmt.
  • Das allgemeine Stück, das als Framework bezeichnet wird, wird von Microsoft geschrieben.
  • Der spezifische Teil, der als KMDF-Treiber bezeichnet wird, kann von Microsoft oder einem unabhängigen Hardwareanbieter geschrieben werden.

Diagramm von KMDF als generisches Treiberpaar.

Der Framework-Teil des Treiberpaars führt allgemeine Aufgaben aus, die für eine Vielzahl von Treibern gelten. Das Framework kann z. B. E/A-Anforderungswarteschlangen, die Threadsynchronisierung und einen großen Teil der Aufgaben zur Energieverwaltung handhaben.

Das Framework besitzt die Verteilertabelle für den KMDF-Treiber. Wenn also jemand ein E/A-Anforderungspaket (IRP) an das (KMDF-Treiber, Framework)-Paar sendet, geht das IRP an das Framework. Wenn das Framework das IRP selbst verarbeiten kann, ist der KMDF-Treiber nicht beteiligt. Wenn das Framework das IRP nicht selbst verarbeiten kann, erhält es Hilfe durch den Aufruf von Ereignishandlern, die vom KMDF-Treiber implementiert werden. Nachfolgend finden Sie einige Beispiele für Ereignishandler, die von einem KMDF-Treiber implementiert werden können.

  • EvtDevicePrepareHardware
  • EvtIoRead
  • EvtIoDeviceControl
  • EvtInterruptIsr
  • EvtInterruptDpc
  • EvtDevicePnpStateChange

Beispielsweise verfügt ein USB 2.0-Hostcontrollertreiber über ein bestimmtes Element namens usbehci.sys und ein allgemeines Element mit dem Namen usbport.sys. Usbehci.sys, der als USB 2.0 Miniport-Treiber bezeichnet wird, verfügt über Code, der für USB 2.0-Hostcontroller spezifisch ist. Usbport.sys, der als USB-Porttreiber bezeichnet wird, hat allgemeinen Code, der sowohl für USB 2.0 als auch für USB 1.0 gilt. Das Treiberpaar (usbehci.sys, usbport.sys) kombiniert sich, um einen einzelnen WDM-Treiber für einen USB 2.0-Hostcontroller zu bilden.

Die (spezifischen, allgemeinen) Treiberpaare weisen eine Vielzahl von Namen in verschiedenen Gerätetechnologien auf. Die meisten gerätespezifischen Treiber weisen das Präfix mini-auf. Die allgemeinen Treiber werden häufig als Port- oder Klassentreiber bezeichnet. Hier sind einige Beispiele für (bestimmte, allgemeine) Paare:

  • (Anzeige-Miniporttreiber, Anzeige-Porttreiber)
  • (USB-Miniport-Treiber, USB-Port-Treiber)
  • (Akku-Miniklassentreiber, Akkuklassentreiber)
  • (HID-Minidriver, HID-Klassentreiber)
  • (Speicher-Miniporttreiber, Speicherporttreiber)

Da immer mehr Treiberpaar-Modelle entwickelt wurden, wurde es schwierig, den Überblick über all die verschiedenen Möglichkeiten zu behalten, einen Treiber zu entwickeln. Jedes Modell verfügt über eine eigene Schnittstelle für die Kommunikation zwischen dem gerätespezifischen Treiber und dem allgemeinen Treiber. Der Wissensstand, der zum Entwickeln von Treibern für eine Gerätetechnologie (z. B. Audio) erforderlich ist, kann sich ganz von dem Wissen unterscheiden, das zum Entwickeln von Treibern für eine andere Gerätetechnologie erforderlich ist (z. B. Speicher).

Im Laufe der Zeit haben Entwickler festgestellt, dass es gut wäre, ein einzelnes einheitliches Modell für Kernelmodus-Treiberpaare zu haben. Das Kernel Mode Driver Framework (KMDF), das erstmals in Windows Vista verfügbar war, erfüllt dieses Bedürfnis. Ein Treiber, der auf KMDF basiert, verwendet ein Paradigma, das vielen technologiespezifischen Treiberpaarmodellen ähnelt.

  • Der Treiber ist in zwei Teile unterteilt: ein Teil für die allgemeine Verarbeitung und ein Teil für die spezifische Verarbeitung eines bestimmten Geräts.
  • Das allgemeine Stück, das von Microsoft geschrieben wird, wird als Framework bezeichnet.
  • Der spezifische Teil, der von Microsoft oder einem unabhängigen Hardwareanbieter geschrieben wird, wird als KMDF-Treiber bezeichnet.

Der USB 3.0-Hostcontrollertreiber ist ein Beispiel für einen Treiber, der auf KMDF basiert. In diesem Beispiel sind beide Treiber des Paares von Microsoft geschrieben. Der allgemeine Treiber ist das Framework, und der gerätespezifische Treiber ist der USB 3.0-Hostcontrollertreiber. Dieses Diagramm veranschaulicht den Geräteknoten und den Gerätestapel für einen USB 3.0-Hostcontroller.

Diagramm des Gerätestapels für usb 3-Hostcontroller.

Im Diagramm ist Usbxhci.sys der USB 3.0-Hostcontrollertreiber. Es ist mit Wdf01000.sys gekoppelt, das das Framework darstellt. Das (usbxhci.sys, wdf01000.sys) -Paar bildet einen einzelnen WDM-Treiber, der als Funktionstreiber für den USB 3.0-Hostcontroller dient. Beachten Sie, dass das Treiberpaar eine Ebene im Gerätestapel belegt und durch ein einzelnes Geräteobjekt dargestellt wird. Das einzelne Geräteobjekt, das das (usbxhci.sys, wdf01000.sys) -Paar darstellt, ist das funktionale Geräteobjekt (FDO) für den USB 3.0-Hostcontroller.

In einem (KMDF-Treiber, Framework)-Paar verarbeitet das Framework Aufgaben, die einer Vielzahl von Kernel-Mode-Treibern gemeinsam sind. Das Framework kann z. B. die Warteschlangen von E/A-Anforderungen, die Threadsynchronisierung, die meisten Plug-and-Play-Aufgaben und die meisten Energieverwaltungsaufgaben verarbeiten. Der KMDF-Treiber verarbeitet Aufgaben, die eine Interaktion mit einem bestimmten Gerät erfordern. Der KMDF-Treiber nimmt an der Verarbeitung von Anforderungen teil, indem Ereignishandler registriert werden, die das Framework nach Bedarf aufruft.