Condividi tramite


Supporto di client Kernel-Mode nei driver UMDF

Questo argomento descrive come un driver UMDF (Driver Framework) di User-Mode supporta i client in modalità kernel, a partire da UMDF versione 2.

Un client in modalità kernel è un driver in modalità kernel che invia richieste di I/O al driver UMDF. Il driver in modalità kernel potrebbe trovarsi sopra il driver UMDF, nello stesso stack di dispositivi o in uno stack di dispositivi diverso.

Il driver in modalità kernel può inoltrare richieste di I/O ricevute da un'applicazione in modalità utente oppure creare nuove richieste di I/O e inviarle al driver in modalità utente.

Come supportare i client in modalità kernel in un driver UMDF

Per abilitare il supporto di un driver UMDF per i client in modalità kernel, il file INF del driver UMDF deve includere la direttiva UmdfKernelModeClientPolicy nella sezioneWDF della direttiva INF DDInstall.

Il framework fornisce due metodi utili per i driver che supportano i client in modalità kernel. Un driver può chiamare il metodo WdfRequestGetRequestorMode per determinare se una richiesta di I/O proviene dalla modalità kernel o dalla modalità utente. Se la richiesta di I/O proviene dalla modalità utente, il driver può chiamare WdfRequestIsFromUserModeDriver per determinare se la richiesta proviene da un'applicazione o da un altro driver in modalità utente.

Restrizioni sui driver in modalità kernel

Un driver UMDF può elaborare le richieste di I/O da un driver in modalità kernel solo se il driver in modalità kernel soddisfa i requisiti seguenti:

  • Il driver in modalità kernel deve essere in esecuzione in IRQL = PASSIVE_LEVEL quando invia la richiesta di I/O.

  • A meno che il driver non abbia impostato la direttiva UmdfFileObjectPolicy INF su AllowNullAndUnknownFileObjects, ogni richiesta di I/O inviata da un driver in modalità kernel a un driver in modalità utente deve avere un oggetto file associato. Il framework deve essere stato precedentemente informato che il gestore di I/O ha creato l'oggetto file. Tale notifica fa sì che il framework chiami la funzione di callback evtDeviceFileCreate del driver in modalità utente, ma tale funzione di callback è facoltativa.

  • La richiesta di I/O non può contenere un codice di funzione IRP_MJ_INTERNAL_DEVICE_CONTROL.

  • I buffer della richiesta di I/O non devono contenere puntatori a informazioni aggiuntive, perché il driver in modalità utente non può dereferenziare i puntatori.

  • Se la richiesta di I/O contiene un codice di controllo I/O che specifica il metodo di accesso al buffer "nessuno", il driver in modalità kernel deve inviare la richiesta di I/O nel contesto del processo dell'applicazione che ha creato la richiesta di I/O. Per altre informazioni su come supportare il metodo "nessuno" in un driver UMDF, vedere Gestione dei metodi di accesso al buffer nei driver UMDF.

  • Il driver UMDF potrebbe modificare i dati di output di una richiesta di I/O, in modalità utente. Di conseguenza, il driver in modalità kernel deve convalidare tutti i dati di output ricevuti dal driver in modalità utente.

  • Il client in modalità kernel deve in genere convalidare il valore Information che un driver UMDF passa a WdfRequestCompleteWithInformation. Se il client è un driver KMDF, può chiamare WdfRequestGetCompletionParams per ottenere queste informazioni all'interno di una struttura IO_STATUS_BLOCK.

    In genere, il framework non convalida il valore delle informazioni che un driver UMDF passa a WdfRequestCompleteWithInformation. (Il parametro specifica in genere il numero di byte trasferiti.) Il framework convalida il valore delle informazioni solo per i buffer di output e solo per il metodo di accesso ai dati con I/O memorizzato nel buffer. Ad esempio, il framework verifica che il numero di byte trasferiti non superi le dimensioni del buffer di output di un'operazione di lettura, se il metodo di accesso viene memorizzato nel buffer di I/O.