Verwenden Self-Managed E/A

Die meisten frameworkbasierten Treiber nutzen die PnP- und Energieverwaltungsfunktionen des Frameworks für die von ihnen unterstützten Geräte. Anders ausgedrückt: Die meisten frameworkbasierten Treiber ermöglichen es dem Framework, die PnP- und Energiezustände eines Geräts zu verwalten, indem es die folgenden Aktionen ausführt:

• Bereitstellen der Rückruffunktionen EvtDeviceD0Entry und EvtDeviceD0Exit .

• Bereitstellen der Rückruffunktionen EvtDevicePrepareHardware und EvtDeviceReleaseHardware .

• Verwenden von stromverwalteten Warteschlangen für E/A-Anforderungen, die erfordern, dass sich das Gerät im Arbeitszustand befindet, und Verwenden von Warteschlangen, die nicht für alle anderen Anforderungen mit Strom verwaltet werden.

Einige frameworkbasierte Treiber erfordern jedoch eine bessere Kenntnis des Zustands ihrer Geräte, einschließlich Treibern in den folgenden Situationen:

• Die Vorgänge, die ein Treiber ausführt, werden nicht durch eine Reihe von E/A-Anforderungen bestimmt, die der Treiber von Framework-E/A-Warteschlangen empfängt.

• Ein Treiber kommuniziert mit älteren Nicht-Framework-Treibern und befasst sich direkt mit WDM-Schnittstellen.

• Die E/A-Anforderungen, die ein Treiber empfängt, können nicht in zwei Gruppen unterteilt werden: diejenigen, die erfordern, dass sich das Gerät im Betriebszustand befindet, und diejenigen, die nicht.

Die meisten Treiber befinden sich nicht in einer der vorherigen Situationen, aber wenn Ihr Treiber dies ist, muss er möglicherweise eine direktere Kontrolle über die PnP- und Energieverwaltungsvorgänge des Geräts haben. Solche Treiber können selbstverwaltete E/A-Vorgänge verwenden. Die Verwendung von selbstverwalteter E/A bedeutet, dass der Treiber (über eine Reihe von Rückruffunktionen) benachrichtigt wird, wenn seine Geräte angeschlossen oder nicht angeschlossen sind und wenn das Gerät vorübergehend angehalten wird.

Beachten Sie, dass ein Treiber selbstverwaltete E/A-Vorgänge verwenden und weiterhin die E/A-Warteschlangen des Frameworks verwenden kann, entweder als vom Strom verwaltete Warteschlangen oder nicht. Beispielsweise kann ein Treiber die E/A-Warteschlangen des Frameworks verwenden, nicht mit energieverwalteten, mit einer Reihe von selbstverwalteten E/A-Rückruffunktionen.

Um selbstverwaltete E/A zu verwenden, registriert der Treiber einen zusätzlichen Satz von Ereignisrückruffunktionen, wenn er WdfDeviceInitSetPnpPowerEventCallbacks aufruft. Diese Ereignisrückruffunktionen sind:

• EvtDeviceSelfManagedIoInit, der die E/A-Vorgänge des Geräts initialisiert und startet.

• EvtDeviceSelfManagedIoSuspend, wodurch E/A-Vorgänge angehalten werden.

• EvtDeviceSelfManagedIoRestart, der die E/A-Vorgänge des Geräts neu startet, nachdem sie angehalten wurden.

• EvtDeviceSelfManagedIoFlush, der nicht bereitgestellte E/A-Anforderungen entfernt.

• EvtDeviceSelfManagedIoCleanup, das die Zuordnung von Ressourcen aufgibt, die von EvtDeviceSelfManagedIoInit zugeordnet wurden.

Wenn Ihr Gerät zum ersten Mal in den Arbeitszustand (D0) wechselt, ruft das Framework die EvtDeviceSelfManagedIoInit-Rückruffunktion Ihres Treibers auf. Dies geschieht jedes Mal, wenn ein Benutzer Ihr Gerät an das System ansteckt und jedes Mal, wenn das System neu gestartet wird.

Es gibt drei Umstände, unter denen ein Treiber die E/A-Vorgänge eines Geräts beenden muss: Das Gerät wechselt in einen Energiesparzustand, es wird entfernt oder wurde bereits unerwartet entfernt. In der folgenden Liste werden diese Umstände im Detail untersucht:

• Das Gerät wechselt in einen Energiesparzustand und kehrt schließlich in den Betriebszustand zurück.

  Wenn Ihr Gerät im Begriff ist, in einen Low-Power-Zustand zu wechseln (weil sich entweder Ihr Gerät im Leerlauf befindet, das gesamte System in einen Energiesparmodus wechselt oder der PnP-Manager Systemhardwareressourcen neu verteilt), ruft das Framework die EvtDeviceSelfManagedIoSuspend-Rückruffunktion Ihres Treibers auf. Nachdem das Gerät seinen Arbeitszustand erneut aktiviert hat, ruft das Framework die Rückruffunktion EvtDeviceSelfManagedIoRestart Ihres Treibers auf.

• Das Gerät wird entfernt.

  Um die vom Benutzer angeforderte Geräteentfernung zu behandeln, ruft das Framework die EvtDeviceSelfManagedIoSuspend-Rückruffunktion Ihres Treibers auf, bevor das Gerät beendet wird. Nach dem Beenden des Geräts ruft das Framework die Rückruffunktion EvtDeviceSelfManagedIoFlush Ihres Treibers auf. Nachdem das Gerät entfernt wurde, ruft das Framework die Rückruffunktion EvtDeviceSelfManagedIoCleanup auf.

• Das Gerät wurde bereits unerwartet entfernt (überraschende Entfernung).

  Wenn der Treiber für den Gerätebus feststellt, dass das Gerät nicht mehr vorhanden ist, oder wenn ein anderer Treiber im Stapel feststellt, dass das Gerät nicht reagiert, informiert der Treiber, der das Problem erkannt hat, den PnP-Manager. Der PnP-Manager informiert dann den Rest der Treiber darüber, dass das Gerät nicht mehr vorhanden ist. Für frameworkbasierte Treiber empfängt das Framework die Nachricht des PnP-Managers und ruft die Rückruffunktionen EvtDeviceSelfManagedIoSuspend, EvtDeviceSelfManagedIoFlush und EvtDeviceSelfManagedIoCleanup Ihres Treibers auf.

  (Ihr Treiber kann auch eine EvtDeviceSurpriseRemoval-Rückruffunktion registrieren. Wenn sich das Gerät beim Entfernen im Betriebszustand (D0) befand, ruft das Framework EvtDeviceSurpriseRemoval auf, bevor es die selbstverwalteten E/A-Rückruffunktionen aufruft. Wenn sich das Gerät beim Entfernen in einem Energiesparzustand befand, wird EvtDeviceSurpriseRemoval nach EvtDeviceSelfManagedIoSuspend aufgerufen.

Weitere Informationen zur Reihenfolge, in der das Framework die Ereignisrückruffunktionen eines Treibers aufruft, finden Sie unter PnP- und Energieverwaltungsszenarien.

Obwohl es selten erforderlich ist, ermöglicht das Framework Treibern, noch mehr Kontrolle über die PnP- und Energiezustände eines Geräts zu haben, indem sie auf die Zustandscomputer im Framework zugreifen.