Riesecuzione delle richieste di I/O

I driver possono accodare nuovamente le richieste di I/O ottenute da una coda di I/O. Un driver può accodare nuovamente una richiesta di I/O a un'altra coda di I/O creata dal driver per lo stesso dispositivo. Inoltre, un driver del bus può accodare nuovamente una richiesta di I/O da una coda di I/O di un dispositivo figlio alla coda di I/O di un dispositivo padre.

Riesecuzione di una richiesta di I/O a una coda di I/O diversa per un dispositivo

Dopo che i gestori di richieste di un driver ricevono una richiesta di I/O dalla coda di I/O di un driver, il driver può chiamare WdfRequestForwardToIoQueue per accodare nuovamente la richiesta a un'altra coda.

Ad esempio, se si vuole che il driver allochi risorse a una richiesta prima di elaborare la richiesta, la funzione di callback EvtIoDefault del driver potrebbe ricevere tutte le richieste, archiviare le informazioni sulle risorse nella memoria del contesto di ogni richiesta e quindi chiamare WdfRequestForwardToIoQueue per accodare nuovamente ogni richiesta a una coda aggiuntiva.

Se il driver chiama WdfRequestForwardToIoQueue per accodare nuovamente una richiesta di I/O che il driver ottenuto da una coda di I/O che usa il metodo di invio sequenziale, il framework recapita la successiva richiesta di I/O dalla coda sequenziale al driver senza attendere il completamento della richiesta di accodamento.

Se il driver usa il metodo di invio manuale, può chiamare il metodo WdfRequestRequeue per restituire una richiesta di I/O all'intestazione della coda di I/O da cui è stato ottenuto dal driver. Dopo aver chiamato WdfRequestRequeue, la chiamata successiva del driver a WdfIoQueueRetrieveNextRequest recupera la richiesta rieseguita.

Riesecuzione di una richiesta di I/O a una coda di I/O di un dispositivo padre

Un driver di funzione per un dispositivo padre può fungere da driver del bus che enumera i dispositivi figlio del dispositivo padre e crea oggetti dispositivo fisico (PDO) per i dispositivi figlio. Tali driver possono talvolta ricevere richieste di I/O per un dispositivo figlio che il dispositivo padre deve gestire.

Ad esempio, un bus di protocollo (ad esempio USB) controlla in genere le risorse hardware assegnate a ogni dispositivo connesso. Di conseguenza, il driver di funzione per il bus padre gestisce in genere le operazioni di I/O per ogni dispositivo figlio. Quando il gestore di I/O invia una richiesta di I/O allo stack di dispositivi di uno dei dispositivi figlio, il driver di funzione per il bus riceve la richiesta di I/O in una delle code di I/O del dispositivo figlio, perché tale driver ha creato il PDO del dispositivo figlio. Prima che il driver possa elaborare la richiesta di I/O nel contesto del dispositivo bus padre, deve accodare nuovamente la richiesta di I/O dalla coda di I/O del dispositivo figlio a una coda di I/O appartenente al dispositivo padre.

Tuttavia, i driver non possono chiamare WdfRequestForwardToIoQueue per spostare le richieste dalla coda di un figlio alla coda di un padre. Poiché il gestore di I/O crea stack di dispositivi separati per i dispositivi padre e figlio, l'oggetto dispositivo WDM sottostante deve prima essere modificato da uno che rappresenta il dispositivo figlio a uno che rappresenta l'elemento padre.

Prima della versione 1.9 di KMDF, i driver potrebbero inviare richieste di I/O da un dispositivo figlio solo creando destinazioni di I/O remote, aumentando le dimensioni dello stack di dispositivi del dispositivo figlio e specificando l'oggetto dispositivo WDM corretto.

A partire dalla versione 1.9 di KMDF, un driver può chiamare WdfPdoInitAllowForwardingRequestToParent prima di creare un dispositivo figlio e quindi chiamare WdfRequestForwardToParentDeviceIoQueue per rieseguire una richiesta dalla coda di I/O del figlio a una coda padre. Se un driver usaWdfPdoInitAllowForwardingRequestToParent e WdfRequestForwardToParentDeviceIoQueue, il framework aumenta le dimensioni dello stack di dispositivi figlio e assegna l'oggetto dispositivo WDM corretto alla richiesta di I/O.