Configurazione e utilizzo delle code dei dispositivi

Un driver configura un oggetto coda di dispositivi chiamando KeInitializeDeviceQueue all'inizializzazione del driver o del dispositivo. Dopo aver avviato il/i dispositivo(i), il driver inserisce gli IRP in questa coda chiamando KeInsertDeviceQueue o KeInsertByKeyDeviceQueue. La figura seguente illustra queste chiamate.

Come illustrato nella figura, il driver deve fornire lo spazio di archiviazione per un oggetto coda del dispositivo, che deve essere residente. I driver che configurano un oggetto coda di dispositivi in genere forniscono lo spazio di archiviazione necessario nell'estensione del dispositivo di un oggetto dispositivo creato dal driver, ma l'archiviazione può trovarsi in un'estensione del controller se il driver usa un oggetto controller o in un pool non a pagina allocato dal driver.

Se il driver fornisce spazio di archiviazione per l'oggetto coda dei dispositivi in una estensione del dispositivo, chiama KeInitializeDeviceQueue dopo aver creato l'oggetto dispositivo e prima di avviare il dispositivo. In altre parole, il driver può inizializzare la coda dalla routine AddDevice o quando gestisce una richiesta di IRP_MN_START_DEVICE PnP. Nella chiamata a KeInitializeDeviceQueue, il driver passa un puntatore allo spazio di memoria che fornisce per l'oggetto della coda del dispositivo.

Dopo aver avviato i dispositivi, il driver può inserire un IRP nella coda dei dispositivi chiamando KeInsertDeviceQueue, che posiziona l'IRP alla fine della coda o KeInsertByKeyDeviceQueue, che inserisce l'IRP nella coda in base a un valore sortKey determinato dal driver, come illustrato nella figura precedente.

Ognuna di queste routine di supporto restituisce un valore booleano che indica se l'IRP è stato inserito nella coda. Ognuna di queste chiamate imposta anche lo stato dell'oggetto coda del dispositivo su Occupato se la coda è attualmente vuota (Not-Busy). Tuttavia, se la coda è vuota (Not-Busy), né la routine KeInsertXxxDeviceQueue inserisce l'IRP nella coda. Imposta invece lo stato dell'oggetto coda del dispositivo su Occupato e restituisce FALSE. Poiché l'IRP non è stato accodato, il driver deve passarlo a un'altra routine del driver per una successiva elaborazione.

Quando si configurano code di dispositivi supplementari, seguire questa linea guida di implementazione:

Quando una chiamata a KeInsertXxxDeviceQueue restituisce FALSE, il chiamante deve passare l'IRP che ha tentato di accodare per un'ulteriore elaborazione a un'altra routine del driver. Tuttavia, la chiamata a KeInsertXxxDeviceQueue modifica lo stato dell'oggetto coda del dispositivo a Occupato, quindi l'IRP successivo in arrivo viene inserito nella coda a meno che il driver non richiami prima KeRemoveXxxDeviceQueue.

Quando lo stato dell'oggetto coda del dispositivo è impostato su Occupato, il driver può estrarre un IRP dalla coda per un'ulteriore elaborazione o reimpostare lo stato su Not-Busy chiamando una delle routine di supporto seguenti:

• KeRemoveDeviceQueue per rimuovere l'IRP all'inizio della coda

• KeRemoveByKeyDeviceQueue per rimuovere un IRP scelto in base a un valore SortKey determinato dal driver

• KeRemoveEntryDeviceQueue per rimuovere una determinata IRP nella coda o per determinare se un determinato IRP si trova nella coda

  KeRemoveEntryDeviceQueue restituisce un valore booleano che indica se l'IRP si trovava nella coda del dispositivo.

Chiamare una di queste routine per rimuovere una voce da una coda del dispositivo che è vuota ma occupata modifica lo stato della coda in Non Occupata.

Ogni oggetto coda del dispositivo è protetto da un blocco di selezione esecutivo predefinito (non visualizzato nella figura Using a Device Queue Object). Di conseguenza, un driver può inserire gli IRPs nella coda e rimuoverli in modo sicuro per i multiprocessori da qualsiasi routine di driver eseguendo a un livello di priorità minore o uguale a IRQL = DISPATCH_LEVEL. A causa di questa restrizione IRQL, un driver non può chiamare nessuna routine KeXxxDeviceQueue dal suo ISR o dalle routine SynchCritSection, che vengono eseguite a DIRQL.

Per altre informazioni, vedere Managing Hardware Priorities e Spin Locks. Per i requisiti IRQL per una routine di supporto specifica, vedere la pagina di riferimento della routine.