Einführung in Controllerobjekte

Wie der Name schon sagt, stellt ein Controllerobjekt in der Regel einen physischen Gerätecontroller mit angeschlossenen Geräten dar. Ein Nicht-WDM-Treiber der niedrigsten Ebene für eine Reihe ähnlicher Geräte, die von einem physischen Controller koordiniert werden, kann ein Controllerobjekt erstellen und zum Synchronisieren von E/A-Vorgängen zwischen den angeschlossenen Geräten verwenden. Der Treiber implementiert eine ControllerControl-Routine und ruft die Controllerobjektunterstützungsroutinen des E/A-Managers auf.

Im Allgemeinen verwenden Treiber Controllerobjekte, um Vorgänge mit angefügten Geräten zu synchronisieren, wenn die folgenden Kriterien erfüllt sind:

• Der Controller führt keine langen Vorgänge ohne Unterbrechung aus, sodass der Treiber keinen dedizierten Gerätethread erstellen oder Systemarbeitsthreads verwenden muss.

• Die mit dem Controller verbundenen Geräte sind ähnlich. Das heißt, es handelt sich nicht um Geräte mit völlig unterschiedlichen physischen Eigenschaften oder Betriebsfunktionen, z. B. Tastatur- und Mausgeräte, die mit der Tastatur und dem Hilfsgerätecontroller verbunden werden können.

• Der Treiber ist so konzipiert, dass er monolithisch ist: einschichtig in Bezug auf den Gerätecontroller und angeschlossene physische Geräte, anstatt als Porttreiber (für den Controller) mit einem oder mehreren Klassentreibern (für angefügte Geräte) über dem Porttreiber entworfen zu werden.

Treiber von Geräten mit E/A-Kanälen und einer Reihe logischer Geräteobjekte können auch ein Controllerobjekt verwenden, um ihre E/A-Vorgänge zwischen oder zwischen den Kanälen eines solchen Geräts zu synchronisieren.

Ein Controllerobjekt hat keinen Namen und ist daher nicht das Ziel von E/A-Anforderungen. Es handelt sich einfach um einen Synchronisierungsmechanismus zum Serialisieren von E/A aus einer Reihe von Geräteobjekten. Da ein Controllerobjekt keinen Namen hat, ist es für vom Benutzermodus geschützte Subsysteme unsichtbar, die keine Geräte-E/A-Anforderungen ausführen können, ohne ein Handle für das Dateiobjekt zu erhalten, das das Zielgerätobjekt darstellt. Ein Controllerobjekt ist auch für Treiber höherer Ebene unsichtbar, die keine eigenen Geräteobjekte an ein Controllerobjekt anfügen können. Anders ausgedrückt: Weder der E/A-Manager noch ein Treiber auf höherer Ebene kann ein IRP einrichten, das E/A anfordert, auf einem Gerät, das durch ein Controllerobjekt dargestellt wird. E/A-Anforderungen werden immer an Geräteobjekte ausgegeben. Nur der Treiber kann das Controllerobjekt verwenden.

Synchronisierung und überlappende E/A

Monolithische Treiber physischer Geräte mit Features wie denen des "AT"-Datenträgercontrollers müssen zum Synchronisieren ihrer Geräte-E/A-Vorgänge kein Controllerobjekt verwenden. Ein Treiberwriter könnte beispielsweise die folgende Synchronisierungsmethode ausprobieren, anstatt ein Controllerobjekt zu verwenden:

• Richten Sie benannte Geräteobjekte ein, um die Geräte darzustellen, die Ziele für E/A-Anforderungen sind.

• Verwalten Sie Zustandsinformationen (z. B. eine Reihe von Device Busy-Flags in jeder Geräteerweiterung oder in einer einzelnen Geräteerweiterung), die angeben, welches Geräteobjekt das Ziel des aktuellen E/A-Vorgangs ist.

• Führen Sie E/A-Vorgänge für das aktuell ausgelastete Geräteobjekt aus, und stellen Sie eingehende IRPs für andere Geräteobjekte erneut in die Warteschlange, bis die aktuelle IRP abgeschlossen ist.

Das vorherige Synchronisierungsverfahren serialisiert die IRP-Verarbeitung für alle Zielgeräteobjekte des Treibers. Beachten Sie, dass der Treiber auch gezwungen wird, die aktuelle IRP abzuschließen, bevor seine StartIo-Routine mit der Verarbeitung des nächsten IRP beginnen kann, was leider die Treiberleistung beeinträchtigt.

Wenn bestimmte Gerätevorgänge überlappen können, kann die Verwendung eines Controllerobjekts den E/A-Durchsatz eines Treibers erhöhen, da diese Synchronisierungsmethode es dem Treiber ermöglicht, zu bestimmen, ob sich Vorgänge überlappen können, bevor das physische Gerät eingerichtet wird. Ein Datenträgercontroller kann z. B. zulassen, dass der Treiber Suchvorgänge auf einem Datenträger mit Lese-/Schreibvorgängen auf einem anderen Datenträger überlappen kann.

Darüber hinaus ist die Verwendung eines Controllerobjekts eine relativ einfache Möglichkeit, E/A-Vorgänge für mehrere Zielgeräteobjekte über ein einzelnes physisches Gerät zu synchronisieren, z. B. einen "AT"-Datenträgercontroller. Die Verwendung eines Controllerobjekts ermöglicht es einem monolithischen Treiber, E/A-Vorgänge über eine Reihe benannter Geräteobjekte hinweg zu synchronisieren, ohne den Zustand jedes Geräts und des Gerätecontrollers in einer oder mehreren Geräteerweiterungen aufrechterhalten zu müssen, und ohne IRPs erneut in die Warteschlange stellen zu müssen.

Einige Geräte, die für überlappende E/A-Vorgänge konzipiert sind, z. B. serielle Vollduplexcontroller oder Bus-master-Adapter, verfügen jedoch in der Regel über Treiber, die interne Warteschlangen für IRPs einrichten.