WDM-Konzepte für WDF-Treiber
Windows Driver Frameworks (WDF) ist ein Wrapper für WDM-Schnittstellen (Microsoft Windows Driver Model). Obwohl das Framework viele WDM-Konzepte vereinfacht und andere vollständig ausblendet, sodass Sie nicht mit ihnen arbeiten müssen, sollten Sie dennoch einige der grundlegenden Konzepte von WDM-Treibern verstehen. Insbesondere sollten Sie Sich mit Treibertypen, Treiberstapeln, Gerätestapeln und E/A-Anforderungspaketen vertraut machen.
Windows-basierte Treiber sind in drei Typen unterteilt: Bustreiber, Funktionstreiber und Filtertreiber. Bustreiber unterstützen E/A-Busse, indem sie untergeordnete Geräte erkennen, die an einen übergeordneten Bus angeschlossen sind, und ihre Merkmale melden. (Diese Aktivität wird als Busaufzählung bezeichnet.) Funktionstreiber steuern E/A-Vorgänge für Geräte und Busse. Filtertreiber empfangen, überprüfen und ändern möglicherweise Daten, die zwischen Benutzeranwendungen und Treibern oder zwischen einzelnen Treibern fließen.
Treiber für Busse sind im Wesentlichen Funktionstreiber, die auch Kinder auflisten. Ein Fahrer fungiert als "Bustreiber", wenn er die untergeordneten Geräte in einem Bus aufzählt. Andernfalls fungiert derselbe Treiber als "Funktionstreiber" für den Bus, wenn er E/A-Vorgänge verarbeitet, die auf die Hardware des Busadapters zugreifen.
Ein User-Mode Driver Framework(UMDF)-Treiber kann kein Bustreiber sein.
Im Windows-Betriebssystem sind WDM-Treiber in einer vertikalen Aufrufsequenz angeordnet, die als Treiberstapel bezeichnet wird. Der oberste Treiber im Stapel empfängt in der Regel E/A-Anforderungen von Benutzeranwendungen, nachdem die Anforderungen den E/A-Manager des Betriebssystems durchlaufen haben. Die unteren Treiberebenen kommunizieren in der Regel mit Computerhardware.
Ein einfacher Treiberstapel enthält einen Bustreiber am unteren Rand des Stapels, der busspezifische E/A-Vorgänge verarbeitet und die untergeordneten Geräte auflistet, die mit dem Stapel verbunden sind. In der Regel liegen mindestens ein gerätespezifischer Funktionstreiber über dem Bustreiber. Diese Funktionstreiber verarbeiten E/A-Vorgänge für die Geräte, die mit dem Bus verbunden sind. Filtertreiber können sich über den Funktionstreibern befinden, oder sie können sich zwischen einem Bustreiber und einem Funktionstreiber befinden. Ein ausgeführtes System verfügt über mehrere Treiberstapel, die verschiedene Gerätetypen unterstützen.
Jeder Treiberstapel unterstützt mindestens einen Gerätestapel. Ein Gerätestapel ist eine Gruppe von Geräteobjekten , die aus WDM-definierten DEVICE_OBJECT-Strukturen erstellt werden. Jeder Gerätestapel stellt ein Gerät dar. Jeder Treiber erstellt ein Geräteobjekt für jedes seiner Geräte und fügt jedes Geräteobjekt an einen Gerätestapel an. Gerätestapel werden erstellt und entfernt, wenn Geräte ein- und getrennt werden und jedes Mal, wenn das System neu gestartet wird.
Wenn ein Bustreiber erkennt, dass untergeordnete Geräte angeschlossen oder nicht angeschlossen wurden, informiert er den Plug & Play-Manager (PnP). Als Antwort fordert der PnP-Manager den Bustreiber auf, ein physisches Geräteobjekt (PDO) für jedes untergeordnete Gerät zu erstellen, das mit dem übergeordneten Gerät (also dem Bus) verbunden ist. Die PDO wird zum unteren Rand eines Gerätestapels.
Als Nächstes lädt der PnP-Manager Funktions- und Filtertreiber, um jedes Gerät zu unterstützen (sofern sie nicht bereits geladen sind), und dann ruft der PnP-Manager diese Treiber auf, damit jeder ein Geräteobjekt erstellen und es oben im Gerätestapel hinzufügen kann. Funktionstreiber erstellen funktionale Geräteobjekte (FUNCTIONAL Device Objects, FDOs), und Filtertreiber erstellen Filtergeräteobjekte (Filter-DOs).
Wenn der E/A-Manager eine E/A-Anforderung an die Treiber eines Geräts sendet, übergibt er die Anforderung an den Treiber, der das oberste Geräteobjekt im Gerätestapel erstellt hat. Wenn dieser Treiber den E/A-Manager auffordern wird, die Anforderung an den nächstniedrigen Treiber zu übergeben, verwendet der E/A-Manager den Gerätestapel, um den nächstniedrigen Treiber zu ermitteln. (Der nächstniedrige Treiber ist der Treiber, der das nächstniedrige Geräteobjekt erstellt hat.)
WDF erstellt ein Frameworkgeräteobjekt für jedes WDM-Geräteobjekt. Frameworkbasierte Treiber greifen auf diese Frameworkgeräteobjekte anstelle von WDM-Geräteobjekten zu.
Der E/A-Manager sendet die E/A-Anforderungen einer Anwendung an Treiber, indem E/A-Anforderungspakete (IRPs) erstellt werden. Ein IRP kann eine Anforderung zum Ausführen eines E/A-Vorgangs (z. B. einen Lese-/Schreibvorgang) oder eine Anforderung zum Ausführen einer I/O-Steuerungsaktion (IOCTL) enthalten (z. B. zurückgeben status). Darüber hinaus erstellt der PnP-Manager IRPs, die PnP- und Energieverwaltungsvorgänge darstellen, die Treiber ausführen müssen, und sendet diese IRPs an Treiber.
In der Regel erstellt der E/A-Manager einen Lese- oder Schreib-IRP, wenn eine Benutzeranwendung einen Lese- oder Schreibvorgang anfordert. Der E/A-Manager übergibt den IRP an den Treiber am oberen Rand des Treiberstapels, und dieser Treiber verarbeitet entweder die Anforderung oder übergibt die Anforderung an den nächstniedrigen Treiber. Einige Anforderungen werden bis zum Ende des Stapels gesendet, andere werden vollständig von übergeordneten Treibern verarbeitet.
Jedes Mal, wenn ein Treiber eine IRP empfängt, erhält der Treiber auch einen Zeiger auf das Geräteobjekt, das das Gerät darstellt, das den Vorgang verarbeiten muss. Daher verwenden die Treiber in einem Treiberstapel Geräteobjekte, um zu bestimmen, an welche ihrer angeschlossenen Geräte eine bestimmte Anforderung gehen soll.
WDF-Treiber greifen in der Regel nicht direkt auf IRPs zu. Das Framework konvertiert die WDM-IRPs, die Lese-, Schreib- und Geräte-E/A-Steuerungsvorgänge darstellen, in Frameworkanforderungsobjekte, die Kernel-Mode Driver Framework (KMDF) und UMDF-Treiber in E/A-Warteschlangen empfangen. Das Framework verarbeitet PnP- und Energieverwaltungs-IRPs intern und verwendet Ereignisrückruffunktionen, um den Treiber über PnP- und Energieereignisse zu informieren.