Behandeln einer Set-Power Request

Ein Zwischentreiber muss Anforderungen zum Festlegen der Stromversorgung auf den Arbeitszustand (ein Netzgeräte-Energiezustand von D0) und auf ruheende Zustände (einen Netzgeräte-Energiezustand von D1, D2 oder D3) verarbeiten. Der Zwischentreiber sollte auch Energiezustandsvariablen und eine StandBy-Kennzeichnung Standard. Diese Themen werden in diesem Thema weiter diskutiert.

Beispiele für die Verwaltung von Fortgeschrittenetreibern finden Sie im NDIS MUX Intermediate Driver and Notify Object Driver Sample im Windows-Treiberbeispielrepository auf GitHub.

Behandeln einer set Power Request in einen Ruhezustand

Es gibt zwei Fälle, in denen ein Zwischentreiber eine festgelegte Leistungsanforderung für einen Ruhezustand verarbeiten muss:

• NDIS fordert an, dass der virtuelle Miniport oberer Rand des Zwischentreibers in einen Ruhezustand wechselt.

• Der untere Rand des Zwischentreibers behandelt den zugrunde liegenden Miniporttreiberübergang in einen Ruhezustand, wenn er eine Plug & Play (PnP)-Ereignisbenachrichtigung empfängt.

Diese Ereignisse können in beliebiger Reihenfolge stattfinden, und ein Ereignis begleitet nicht unbedingt die andere.

Wenn der virtuelle Miniport oberer Rand des Zwischentreibers eine Anforderung zum Festlegen der Leistung auf einen Ruhezustand empfängt, lautet die Abfolge von Ereignissen für die Verarbeitung der Anforderung wie folgt:

1. NDIS ruft die ProtocolNetPnPEvent-Funktion jedes Protokolltreibers auf, der an den virtuellen Miniport gebunden ist. Der Aufruf von ProtocolNetPnPEvent gibt ein NetEventSetPower-Ereignis für einen Ruhezustand an. Protokolltreiber, die an den Zwischentreiber gebunden sind, beenden das Senden von Netzwerkdaten und senden OID-Anforderungen an den virtuellen Miniport des Zwischentreibers. Der untere Protokollrand des Zwischentreibers kann weiterhin Netzwerkdaten und Anforderungen nach unten senden, bis NDIS angibt, dass der zugrunde liegende Miniporttreiber den Übergang zu einem Ruhezustand macht.

2. NDIS hält die übermäßigen Treiber und dann den virtuellen Miniport an, nachdem das NetEventSetPower-Ereignis ausgestellt wurde. Der angegebene Grund für die Pause ist ein Übergang zu einem Energiesparzustand. Weitere Informationen zum Anhalten eines virtuellen Miniports finden Sie unter Anhalten eines Adapters.

   Hinweis : Keine OID-Anforderungen können an den virtuellen Miniport gesendet werden, während es sich in einem Energiesparzustand befindet, mit Ausnahme von OID_PNP_SET_POWER.

3. NDIS gibt eine OID_PNP_SET_POWER Anforderung an den virtuellen Miniport des Zwischentreibers aus. Der Zwischentreiber akzeptiert die Anforderung, indem NDIS_STATUS_SUCCESS zurückgegeben wird. Der Zwischentreiber darf die OID_PNP_SET_POWER Anforderung nicht an den zugrunde liegenden Miniporttreiber weitergeben. Nachdem der Zwischentreiber diese Anforderung abgeschlossen hat, sollte er keine weiteren empfangenen Netzwerkdaten angeben oder den Status angeben, auch wenn er Netzwerkdaten und Statusanzeigen vom zugrunde liegenden Miniporttreiber empfängt.

Wenn der untere Protokollrand des Zwischentreibers den zugrunde liegenden Miniporttreiber in einen Ruhezustand übergibt, lautet die Abfolge von Ereignissen für die Behandlung des Übergangs wie folgt:

1. NDIS ruft die ProtocolNetPnPEvent-Funktion des unteren Rands des Zwischentreiberprotokolls auf. Der Aufruf von ProtocolNetPnPEvent gibt ein NetEventSetPower-Ereignis für einen Ruhezustand an. Der Zwischentreiber muss das Senden von Netzwerkdaten beenden und OID-Anforderungen an den zugrunde liegenden Miniporttreiber senden. Wenn es ausstehende Anforderungen gibt oder sendet, sollte der Zwischentreiber NDIS_STATUS_PENDING vom Aufruf an ProtocolNetPnPEvent zurückgeben. Der Zwischentreiber ruft NdisCompleteNetPnPEvent auf, um den Aufruf von ProtocolNetPnPEvent abzuschließen. Der Protokollrand eines Zwischentreibers kann weiterhin Paket- und Statusanzeigen vom zugrunde liegenden Miniporttreiber abrufen. Empfangene Netzwerkdaten können ignoriert werden. Wenn die Implementierung eines Zwischentreibers von der Überwachung des Status des zugrunde liegenden Miniporttreibers abhängt, sollten statusanzeigen weiterhin überwacht werden.

2. NDIS hält den Protokollrand des Zwischentreibers an und hält den zugrunde liegenden Miniportadapter nach dem Ausgeben des NetEventSetPower-Ereignisses an. Der angegebene Grund für die Pause ist ein Übergang zu einem Energiesparzustand. Weitere Informationen zum Anhalten einer Protokollbindung finden Sie unter Anhalten einer Bindung.

   Hinweis: Es können keine OID-Anforderungen an den zugrunde liegenden Miniportadapter gesendet werden, während es sich im Energiesparmodus befindet, mit Ausnahme von OID_PNP_SET_POWER.

3. NDIS gibt eine OID_PNP_SET_POWER Anforderung an den zugrunde liegenden Miniporttreiber aus. Wenn der zugrunde liegende Miniporttreiber jedoch keine Energieverwaltung unterstützt, wird er angehalten. In diesem Fall fordert NDIS den zugrunde liegenden Miniporttreiber nicht an, das Zwischentreiberprotokoll wird nicht anfordert, die Verbindung vom zugrunde liegenden Miniporttreiber und der NIC aufzuheben. Nachdem der zugrunde liegende Miniporttreiber die Verarbeitung des OID erfolgreich abgeschlossen hat (oder der Miniporttreiber angehalten wurde), gibt er keine weiteren Netzwerkdaten oder -status an.

Behandeln einer set Power Request auf den Arbeitszustand

Es gibt zwei Fälle, in denen ein Zwischentreiber eine festgelegte Leistungsanforderung an den Arbeitszustand verarbeitet:

• NDIS fordert an, dass der obere Rand des virtuellen Miniports des Zwischentreibers in den Arbeitszustand wechselt.

• Der untere Rand des mittleren Treiberprotokolls behandelt den zugrunde liegenden Miniporttreiberübergang in den Arbeitszustand, wenn er eine Plug & Play (PnP)-Ereignisbenachrichtigung empfängt.

Diese Ereignisse können in beliebiger Reihenfolge auftreten, und ein Ereignis begleitet nicht unbedingt die andere.

Wenn der virtuelle Miniport am oberen Rand des Zwischentreibers eine Anforderung zum Festlegen der Leistung auf einen Arbeitszustand erhält, lautet die Abfolge von Ereignissen für die Verarbeitung der Anforderung wie folgt:

1. NDIS gibt einen OID_PNP_SET_POWER an den virtuellen Miniport des Zwischentreibers aus. Der Zwischentreiber gibt NDIS_STATUS_SUCCESS an die festgelegte Energieanforderung zurück. Der Zwischentreiber darf die OID_PNP_SET_POWER Anforderung nicht an den zugrunde liegenden Miniporttreiber weitergeben.

2. NDIS startet den virtuellen Miniport neu und startet dann die übermäßigen Treiber nach dem Ausstellen des OID-Satzes neu. Weitere Informationen zum Neustart eines virtuellen Miniports finden Sie unter Starten eines Adapters.

3. NDIS ruft die ProtocolNetPnPEvent-Funktion der überlappenden Protokolltreiber auf. Der Aufruf von ProtocolNetPnPEvent gibt ein NetEventSetPower-Ereignis an, um den Arbeitszustand (D0) festzulegen. Gebundene Protokolltreiber können mit dem Senden von Netzwerkdaten an den virtuellen Miniport des Zwischentreibers beginnen.

Wenn der untere Protokollrand des Zwischentreibers den zugrunde liegenden Miniporttreiber in einen Arbeitszustand übergibt, lautet die Abfolge von Ereignissen für die Behandlung des Übergangs wie folgt:

1. NDIS gibt einen OID_PNP_SET_POWER an den zugrunde liegenden Miniporttreiber aus oder ruft seinen MiniportInitializeEx-Handler auf, wenn der zugrunde liegende Miniporttreiber angehalten wurde.

2. NDIS startet den zugrunde liegenden Miniporttreiber neu und anschließend den Protokollrand des Zwischen-NDIS und des zugrunde liegenden Miniportadapters nach dem Ausgeben des OID. Weitere Informationen zum Anhalten einer Protokollbindung finden Sie unter Neustarten einer Bindung.

3. NDIS ruft die ProtocolNetPnPEvent-Funktion des Zwischentreibers auf. Der Aufruf von ProtocolNetPnPEvent gibt ein NetEventSetPower-Ereignis an, um den Arbeitszustand (D0) festzulegen. Der Zwischentreiber kann mit dem Senden von Netzwerkdaten an den zugrunde liegenden Miniporttreiber beginnen.

Power States und das Standby-Flag

Der Zwischentreiber sollte eine separate Leistungszustandsvariable für jede virtuelle Miniportinstanz und für jeden zugrunde liegenden Miniporttreiber, an den der Treiber gebunden ist, Standard enthalten. Der Zwischentreiber sollte auch ein StandingBy-Flag für jeden virtuellen Miniport Standard enthalten:

• Auf TRUE festgelegt, wenn der Energiezustand des virtuellen Miniports oder des zugrunde liegenden Miniporttreibers D0 verlässt.

• Wird auf FALSE festgelegt, wenn der Energiezustand des virtuellen Miniports oder des zugrunde liegenden Miniporttreibers zu D0 zurückkehrt.

Hinweis Für MUX-Zwischentreiber können mehrere virtuelle Miniports vorhanden sein, die einem zugrunde liegenden Miniporttreiber oder mehreren zugrunde liegenden Miniports zugeordnet sind, die jedem virtuellen Miniport zugeordnet sind. Wenn sich der Leistungszustand eines Miniportadapters ändert, ist auch das Verhalten aller zugeordneten Miniports betroffen. Die Auswirkungen des Verhaltens sind implementierungsspezifisch. Beispielsweise kann ein Treiber, der eine LBFO-Lösung (Load Balancing Failover) implementiert, die virtuellen Miniports nicht deaktivieren, wenn ein einzelner zugrunde liegender Miniporttreiber deaktiviert wird. Eine Treiberimplementierung, die von allen zugrunde liegenden Miniporttreibern abhängt, erfordert jedoch die Deaktivierung virtueller Miniports, wenn ein zugrunde liegender Miniporttreiber deaktiviert wird.

Der Zwischentreiber sollte beim Verarbeiten von Anforderungen die Variablen "StandingBy" und "Power State" wie folgt verwenden:

• Die MiniportSendNetBufferLists-Funktion des Treibers sollte fehlschlagen, es sei denn, der virtuelle Miniport und der zugrunde liegende Miniportadapter befinden sich in D0.

• Die MiniportOidRequest-Funktion des Treibers sollte immer erfolgreich OID_PNP_QUERY_POWER sein, um sicherzustellen, dass der Treiber die nachfolgenden OID_PNP_SET_POWER Anforderungen empfängt.

• Die MiniportOidRequest-Funktion des Treibers sollte fehlschlagen, wenn sich der virtuelle Miniport nicht in D0 befindet oder wenn StandingBy WAHR ist. Andernfalls sollte eine einzelne Anforderung in die Warteschlange gestellt werden, wenn sich der zugrunde liegende Miniporttreiber nicht in D0 befindet. Eine in die Warteschlange eingereihte Anforderung sollte verarbeitet werden, wenn der zugrunde liegende Miniporttreiberzustand D0 wird.

• Der virtuelle Miniport des zwischengeschalteten Treibers sollte nur dann den Status melden, wenn sich sowohl der zugrunde liegende Miniporttreiber als auch der virtuelle Miniport in D0 befinden.