Risparmio energia per le code di I/O

Quando il framework riceve una richiesta di I/O indirizzata a uno dei dispositivi del driver, il framework inserisce la richiesta in una coda di I/O. Il driver può ottenere richieste di I/O dalla coda di I/O fornendo gestori di richieste o eseguendo il polling della coda. Per altre informazioni sulle code di I/O, vedere Oggetti coda framework.

Quando si progetta il driver, è necessario raggruppare le richieste di I/O che il driver riceverà in due categorie:

1. Richieste che richiedono che un dispositivo sia nello stato di lavoro (D0), tra cui:

   • Leggere o scrivere richieste che richiedono al driver di funzione del dispositivo di leggere i dati o scrivere dati nel dispositivo.
   • Il controllo del dispositivo richiede che un driver di funzione o bus non possa eseguire il servizio senza accedere al dispositivo.

2. Le richieste che non richiedono che un dispositivo sia nello stato di lavoro (D0), tra cui:

   • Il controllo del dispositivo richiede che un driver di funzione o bus possa funzionare senza accedere al dispositivo.
   • Eventualmente tutte le richieste ricevute da un driver di filtro.
   • Tutte le richieste che tutti i driver in uno stack di driver ricevono, se lo stack supporta un dispositivo solo software che non comunica con alcun hardware.

A meno che non si stia scrivendo un driver di filtro o un driver per uno stack che non comunica con l'hardware, è probabile che il driver riceva alcune richieste che richiedono che il dispositivo sia nello stato di lavoro, insieme ad alcuni che non lo fanno.

Per supportare questi due tipi di richieste, il framework fornisce due tipi di code di I/O: quelle che sono gestite dall'alimentazione e quelle che non sono. Quando il driver crea ognuna delle code di I/O, imposta il membro PowerManaged nella struttura di WDF_IO_QUEUE_CONFIG della coda su WdfTrue o WdfFalse per indicare uno dei seguenti:

• Se il driver imposta PowerManaged su WdfTrue, la coda è gestita dall'alimentazione.

  Quando le richieste di I/O sono disponibili in una coda gestita da energia, il framework recapita le richieste al driver solo se il dispositivo si trova nello stato di lavoro (D0). Pertanto, ogni volta che il driver riceve una richiesta da una coda gestita da alimentazione, il framework garantisce che il dispositivo sia disponibile. Se il dispositivo non è nello stato di funzionamento, il framework archivia le richieste nella coda fino a quando il dispositivo non diventa disponibile.

  Se il dispositivo si trova in uno stato di bassa potenza perché è inattivo e se il framework inserisce una richiesta di I/O in una delle code gestite dal driver, il framework chiede allo stack driver di ripristinare lo stato di funzionamento del dispositivo prima di recapitare la richiesta al driver.

  Se il dispositivo si trova in uno stato di bassa potenza perché il sistema non si trova nello stato di lavoro (S0) e se il framework inserisce una richiesta di I/O in una delle code gestite dal driver, il framework attende fino a quando il dispositivo non torna allo stato funzionante (D0) e quindi recapita la richiesta al driver.

  Poiché il framework non recapita le richieste di I/O da una coda gestita da energia al driver se il dispositivo non si trova nello stato di lavoro, i driver che si trovano sopra ilproprietario dei criteri di alimentazione nello stack di driver non devono usare code di I/O gestite da energia. Se un driver che si trova sopra il proprietario di power policy usa una coda gestita da alimentazione e se il dispositivo si trova in uno stato a bassa potenza, il driver non riceve la richiesta e non può passarlo al proprietario dei criteri di alimentazione. Pertanto, il proprietario dei criteri di alimentazione, che controlla lo stato di alimentazione del dispositivo, non riattiva il dispositivo.

• Se il driver imposta PowerManaged su WdfFalse, la coda non è gestita dall'alimentazione.

  Quando le richieste di I/O sono disponibili in una coda che non è gestita dall'alimentazione, il framework recapita le richieste al driver indipendentemente dal fatto che il dispositivo si trovi nello stato di lavoro (D0). Se si è configurata la coda in modo che riceva solo richieste che non richiedono l'accesso al dispositivo, il driver può eseguire il servizio di ogni richiesta, anche se il dispositivo non è disponibile.

Per altre informazioni sulle code di I/O gestite da energia, vedere Uso di Power-Managed code di I/O.

Alcuni driver richiedono un controllo diretto sulle operazioni di Plug and Play (PnP) e di gestione delle energia. Questi driver possono usare I/O self-managed. Per altre informazioni, vedere Uso di Self-Managed I/O.