Condividi tramite


Vantaggi della scrittura di driver UMDF

Questo argomento descrive i vantaggi della scrittura di un driver User-Mode Driver Framework (UMDF) invece di un driver in modalità kernel.

Quando si scrive un driver UMDF, è possibile usufruire dei vantaggi seguenti:

  • I driver UMDF contribuiscono a una maggiore stabilità del sistema operativo perché hanno accesso solo allo spazio indirizzi del processo in cui vengono eseguiti.

  • Poiché i driver UMDF vengono eseguiti con l'account LocalService , hanno accesso limitato ai dati di un utente o ai file di sistema.

  • I driver in modalità utente operano in un ambiente molto più semplice rispetto ai driver in modalità kernel. Ad esempio, i driver in modalità kernel devono prendere in considerazione IRQL, errori di pagina e contesto del thread. In modalità utente, tuttavia, questi problemi non esistono. I driver in modalità utente vengono sempre eseguiti in un thread diverso dal processo di richiesta e possono sempre accettare errori di pagina.

  • UMDF versione 2 offre parità di funzionalità con KMDF nella maggior parte delle aree. Per un confronto completo, vedere Confronto tra funzionalità di UMDF 2 e KMDF.

  • La versione UMDF 2 facilita la conversione tra KMDF e UMDF. Vedere Come convertire un driver KMDF in un driver UMDF 2 (e viceversa).

  • È possibile eseguire il debug dei driver UMDF usando un debugger in modalità utente o, a partire da UMDF versione 2, un debugger in modalità kernel.

  • È possibile usare i comandi di estensione del debugger Wdfkd.dll con KMDF e a partire da UMDF versione 2. Per altre informazioni, vedere Estensioni del debugger.

Un obiettivo fondamentale del modello WDF complessivo è fornire impostazioni predefinite intelligenti, in modo da potersi concentrare sull'hardware del dispositivo ed evitare di scrivere codice per eseguire attività comuni alla maggior parte dei driver.

Per raggiungere questo obiettivo, il framework è progettato per lavorare con i driver in base al "consenso esplicito". Quando si scrive un driver UMDF, si forniscono routine di callback solo per gli eventi che influiscono sul dispositivo. Ad esempio, alcuni dispositivi richiedono l'intervento immediatamente dopo l'attivazione e subito prima che vengano disattivati. Il driver per un dispositivo di questo tipo può implementare funzioni di callback chiamate dal framework in tali momenti.

Il driver include il codice per gestire solo gli eventi per i quali il dispositivo richiede il supporto specifico del dispositivo. Tutti gli altri eventi possono essere gestiti per impostazione predefinita del framework.

Inoltre, un driver può configurare le code di richieste di I/O in modo che il framework arresti l'invio delle richieste mentre il dispositivo è in stato di bassa potenza e riprende l'invio dopo che il dispositivo è tornato allo stato operativo. Analogamente, se arriva una richiesta di I/O mentre il dispositivo è in stato a basso consumo, il framework può attivare automaticamente il dispositivo.