Gestione di una richiesta di risparmio energia impostata

Un driver intermedio deve gestire le richieste per impostare l'alimentazione sullo stato di lavoro (uno stato di alimentazione del dispositivo di rete di D0) e per gli stati di sospensione (uno stato di alimentazione del dispositivo di rete D1, D2 o D3). Il driver intermedio deve anche mantenere le variabili di stato di alimentazione e un flag StandBy. Questi problemi vengono illustrati più avanti in questo argomento.

Per esempi di gestione dell'energia per i driver intermedi, vedere il driver intermedio NDIS MUX e il driver Notify Object negli esempi di driver di Windows nel repository su GitHub.

Gestire una richiesta di impostazione dell'alimentazione in modalità sospensione

Esistono due casi in cui un driver intermedio deve gestire una richiesta di alimentazione impostata su uno stato di sospensione:

• NDIS richiede che l'interfaccia superiore del miniport virtuale del driver intermedio passi alla modalità di sospensione.

• Il livello inferiore del protocollo del driver intermedio gestisce il passaggio del driver miniport sottostante a uno stato di sospensione quando riceve una notifica di evento Plug and Play (PnP).

Questi eventi possono verificarsi in qualsiasi ordine e un evento non accompagna necessariamente l'altro.

Quando il bordo superiore del miniport virtuale del driver intermedio riceve una richiesta di impostare l'alimentazione su uno stato di sospensione, la sequenza di eventi per la gestione della richiesta è la seguente:

1. NDIS chiama la funzione ProtocolNetPnPEvent di ogni driver di protocollo associato al miniport virtuale. La chiamata a ProtocolNetPnPEvent specifica un evento NetEventSetPower per uno stato di sospensione. I driver di protocollo associati al driver intermedio interrompono l'invio di dati di rete e effettuano richieste OID al miniport virtuale del driver intermedio. Lo strato inferiore del protocollo del driver intermedio può continuare a inviare dati di rete e richieste fino a quando NDIS indica che il driver miniport sottostante sta effettuando la transizione a uno stato di ibernazione.

2. NDIS sospende i driver di overlay e quindi il miniport virtuale dopo l'emissione dell'evento NetEventSetPower. Il motivo specificato per la sospensione è una transizione a uno stato a basso consumo. Per altre informazioni sulla sospensione di un miniport virtuale, vedere Sospensione di un adattatore.

   Nota Nessuna richiesta OID può essere inviata al miniport virtuale mentre è in uno stato a basso consumo, ad eccezione di OID_PNP_SET_POWER.

3. NDIS invia una richiesta di OID_PNP_SET_POWER al miniport virtuale del driver intermedio. Il driver intermedio accetta la richiesta restituendo NDIS_STATUS_SUCCESS. Il driver intermedio non deve propagare la richiesta OID_PNP_SET_POWER al driver miniport sottostante. Dopo che il driver intermedio ha completato questa richiesta, non deve indicare altri dati di rete ricevuti o indicare lo stato, anche se continua a ricevere dati di rete e indicazioni sullo stato dal driver miniport sottostante.

Quando il livello inferiore del protocollo del driver intermedio porta il driver miniport sottostante in uno stato di sospensione, la sequenza di eventi per il processo di transizione è la seguente:

1. NDIS chiama la funzione ProtocolNetPnPEvent dello strato inferiore del driver di livello intermedio. La chiamata a ProtocolNetPnPEvent specifica un evento NetEventSetPower per uno stato di sospensione. Il driver intermedio deve interrompere l'invio di dati di rete ed effettuare richieste OID al driver miniport sottostante. Se sono presenti richieste o invii pendenti, il driver intermedio deve restituire NDIS_STATUS_PENDING dalla chiamata a ProtocolNetPnPEvent. Il driver intermedio chiama NdisCompleteNetPnPEvent per completare la chiamata a ProtocolNetPnPEvent. L'interfaccia del protocollo di un driver intermedio può ancora ricevere indicazioni di stato e pacchetti dal driver miniport sottostante. I dati di rete ricevuti possono essere ignorati. Se l'implementazione di un driver intermedio dipende dal monitoraggio dello stato del driver miniport sottostante, le indicazioni sullo stato devono comunque essere monitorate.

2. NDIS sospende la componente del protocollo del driver intermedio e quindi sospende l'adattatore miniport sottostante dopo l'emissione dell'evento NetEventSetPower. Il motivo specificato per la sospensione è una transizione a uno stato a basso consumo. Per altre informazioni sulla sospensione di un'associazione di protocollo, vedere Sospensione di un'associazione.

   Nota Nessuna richiesta OID può essere inviata all'adattatore miniport sottostante mentre si trova in uno stato a basso consumo, ad eccezione di OID_PNP_SET_POWER.

3. NDIS invia una richiesta di OID_PNP_SET_POWER al driver del miniport sottostante. Tuttavia, se il driver miniport sottostante non supporta la gestione dell'energia, verrà fermato. In questo caso, anche se NDIS interrompe il driver miniport sottostante, non richiede al protocollo intermedio del driver di scollegarsi dal driver miniport sottostante e dal NIC. Dopo che il driver miniport sottostante ha completato correttamente l'elaborazione dell'OID (o il driver miniport è stato interrotto), non indicherà altri dati o stato di rete.

Gestione di una richiesta di impostazione dell'alimentazione allo stato operativo

Esistono due casi in cui un driver intermedio gestisce una richiesta di alimentazione impostata sullo stato di lavoro:

• NDIS richiede che l'interfaccia superiore del miniport virtuale del driver intermedio vada allo stato operativo.

• La parte inferiore del protocollo del driver intermediario gestisce la transizione del driver miniport sottostante allo stato operativo quando riceve una notifica di un evento Plug and Play (PnP).

Questi eventi possono verificarsi in qualsiasi ordine e un evento non accompagna necessariamente l'altro.

Quando il bordo superiore del miniport virtuale del driver intermedio riceve una richiesta di impostare l'alimentazione su uno stato di lavoro, la sequenza di eventi per la gestione della richiesta è la seguente:

1. NDIS rilascia un OID_PNP_SET_POWER al miniport virtuale del driver intermedio. Il driver intermedio restituisce NDIS_STATUS_SUCCESS alla richiesta di alimentazione impostata. Il driver intermedio non deve propagare la richiesta OID_PNP_SET_POWER al driver miniport sottostante.

2. NDIS riavvia il miniport virtuale e quindi riavvia i driver sovrastanti dopo aver emesso l'OID per l'impostazione dell'alimentazione. Per altre informazioni sul riavvio di un miniport virtuale, vedere Avvio di un adattatore.

3. NDIS chiama la funzione ProtocolNetPnPEvent dei driver di protocollo sovrastante. La chiamata a ProtocolNetPnPEvent specifica un evento NetEventSetPower per impostare lo stato di lavoro (D0). I driver di protocollo associati possono iniziare a inviare dati di rete al miniport virtuale del driver intermedio.

Quando il livello inferiore del protocollo del driver intermedio passa il driver miniport sottostante in uno stato operativo, la sequenza di eventi per la gestione della transizione è la seguente:

1. NDIS rilascia un OID_PNP_SET_POWER al driver miniport sottostante o chiama il suo gestore MiniportInitializeEx se il driver miniport sottostante è stato interrotto.

2. NDIS riavvia il driver miniport sottostante e quindi il livello del protocollo intermedio dell'NDIS e l'adattatore miniport sottostante dopo l'emissione dell'OID. Per ulteriori informazioni sulla sospensione di un'associazione di protocollo, vedere Riavvio di un'associazione di protocollo.

3. NDIS chiama la funzione ProtocolNetPnPEvent del driver intermedio. La chiamata a ProtocolNetPnPEvent specifica un evento NetEventSetPower per impostare lo stato di lavoro (D0). Il driver intermedio può iniziare a inviare dati di rete al driver miniport sottostante.

Stati di alimentazione e indicatore di standby

Il driver intermedio deve mantenere una variabile di stato di alimentazione separata per ogni istanza di miniport virtuale e per ogni driver miniport sottostante a cui è associato il driver. Il driver intermedio deve anche mantenere un flag StandingBy per ogni miniport virtuale che è:

• Impostare su TRUE quando lo stato di alimentazione del miniport virtuale o del driver miniport sottostante lascia lo stato D0.

• Impostare su FALSE quando lo stato di alimentazione del miniport virtuale o del driver miniport sottostante torna a D0.

Nota Per i driver intermediari MUX, possono esserci più miniport virtuali associati a un driver miniport sottostante oppure più miniport sottostanti associati a ciascun miniport virtuale. Quando lo stato di alimentazione di qualsiasi adattatore miniport cambia, anche il comportamento di tutti i miniport associati è interessato. La modalità di influenza del comportamento è specifica dell'implementazione. Ad esempio, un driver che implementa una soluzione LBFO (Load Balancing Failover) potrebbe non disattivare i miniport virtuali quando viene disattivato un singolo driver miniport sottostante. Tuttavia, un'implementazione del driver che dipende da tutti i driver miniport sottostanti richiederebbe la disattivazione di miniport virtuali quando qualsiasi driver miniport sottostante viene disattivato.

Il driver intermedio deve usare il flag StandingBy e le variabili di stato di alimentazione durante l'elaborazione delle richieste come indicato di seguito:

• La funzione MiniportSendNetBufferListsdel driverdeve avere esito negativo a meno che il miniport virtuale e la relativa scheda miniport sottostante non siano entrambi in stato D0.

• La funzione MiniportOidRequest del driver deve avere sempre esito positivo con la richiesta di OID_PNP_QUERY_POWER per garantire che il driver riceva le successive richieste di OID_PNP_SET_POWER.

• La funzione MiniportOidRequest del driver dovrebbe fallire se il miniport virtuale non è in D0 o se StandingBy è TRUE. In caso contrario, deve effettuare l'accodamento di una singola richiesta se il driver miniport sottostante non è in D0. Una richiesta messa in coda deve essere gestita quando lo stato del driver miniport sottostante diventa D0.

• Il miniport virtuale gestito dal driver intermedio dovrebbe segnalare lo stato solo se sia il driver miniport sottostante sia il miniport virtuale sono in stato D0.