Condividi tramite

Differenze tra WDM e WDF

Il modello WDM è strettamente legato al sistema operativo. I driver interagiscono direttamente con il sistema operativo chiamando routine del servizio di sistema e modificando le strutture del sistema operativo. Poiché i driver WDM sono componenti attendibili in modalità kernel, il sistema fornisce controlli limitati sull'input del driver.

In confronto, il modello Windows Driver Frameworks (WDF) è incentrato sui requisiti del driver e la libreria framework gestisce la maggior parte delle interazioni con il sistema.

Il framework intercetta le richieste di I/O, esegue azioni predefinite dove appropriato e richiama i callback del driver in base alle esigenze. Il modello WDF è basato su oggetti e basato su eventi. Gli oggetti rappresentano costrutti di driver comuni, ad esempio un dispositivo, un blocco o una coda. Un driver Kernel-Mode Driver Framework (KMDF) o User-Mode Driver Framework (UMDF) contiene un punto di ingresso (DriverEntry), le funzioni di callback correlate agli eventi necessarie per gestire il dispositivo e supportano le funzioni di I/O e qualsiasi altra funzione di utilità interna da cui dipende l'implementazione.

In questa sezione vengono descritte le differenze importanti tra WDM e WDF nelle aree seguenti:

Struttura driver

Entrambi i driver WDM e WDF contengono una routine DriverEntry, una serie di routine chiamate per gestire richieste di I/O specifiche e varie routine di supporto.

In un driver WDM, le routine di gestione I/O mappano a codici IRP principali specifici. Le routine di invio ricevono gli IRP dal gestore di I/O, li analizzano e rispondono di conseguenza.

In un driver WDF, il framework registra le proprie routine di dispatch, che ricevono le IRP (Richieste di Pacchetti I/O) dal gestore di I/O, le analizzano e quindi richiamano le funzioni di callback degli eventi del driver per gestirle. Le funzioni di callback degli eventi in genere eseguono un'attività più specifica rispetto alle routine di invio di I/O generali del driver WDM.

Un driver WDF tipico per un dispositivo Plug and Play contiene:

  • RoutineDriverEntry di.
  • Routine EvtDriverDeviceAdd, simile alla funzione di una routine WDM AddDevice.
  • Una o più code di I/O.
  • Una o più funzioni di callback degli eventi di I/O, simili in funzione alle routine di I/O di un driver WDM DispatchXxx.
  • Callback per gestire gli eventi plug and play e di alimentazione supportati dal driver.
  • Callback per gestire le richieste WMI supportate dal driver. (solo KMDF)
  • Callback aggiuntivi, in base alle esigenze, per la pulizia degli oggetti, la creazione di file, gli obiettivi di I/O e così via.

Oggetti del dispositivo e ruoli del driver

Entrambi i driver WDM e WDF creano uno o più oggetti dispositivo. Ogni oggetto dispositivo rappresenta un ruolo driver che è la destinazione delle richieste di I/O. Un oggetto dispositivo fisico (PDO) rappresenta un driver del bus, un oggetto dispositivo funzionale (FDO) rappresenta un driver di funzione e un oggetto dispositivo filtro (FILTER DO) rappresenta un driver di filtro.

Nei driver WDM, questi ruoli di driver sono impliciti, quindi il driver deve tenere traccia di quale ruolo rappresenta ogni oggetto del dispositivo e rispondere in modo appropriato ai pacchetti di richiesta I/O.

I driver WDF, tuttavia, indicano in modo esplicito se un oggetto dispositivo rappresenta un PDO (solo KMDF), FDO o filtra DO e registra i callback di eventi specifici di tale ruolo. Ad esempio, i PDO sono l'obiettivo delle query dei requisiti delle risorse e delle richieste di espulsione dei dispositivi , mentre i FDO e i DO filtro non gestiscono tali richieste.

Un driver WDF configura ogni oggetto dispositivo per ricevere determinati tipi di richieste di I/O. Il framework chiama il driver per gestire solo le richieste di I/O ed esegue un'azione predefinita per tutte le altre richieste. Se l'oggetto dispositivo rappresenta un driver di filtro, il framework passa tutte le altre richieste al driver inferiore successivo. Se l'oggetto dispositivo rappresenta un bus o un driver di funzione, il framework ha esito negativo per tutti gli altri tipi di richiesta.

Per le richieste di alimentazione e Plug and Play, il framework chiama il driver KMDF o UMDF solo per le richieste appropriate per ogni oggetto dispositivo e al momento appropriato. Ad esempio, un FDO deve rispondere a certe richieste dopo che il PDO sottostante ha già risposto. In un driver WDM, il FDO deve impostare una routine di completamento di I/O, passare l'IRP verso il basso nello stack ed elaborarlo dopo i driver sottostanti. Un driver WDF implementa semplicemente la routine di callback corrispondente e il framework lo chiama dopo il completamento dell'elaborazione dei driver inferiori.

Per informazioni su come creare oggetti dispositivo framework, vedere Creazione di un oggetto dispositivo framework.

Alcuni driver gestiscono anche determinate richieste di I/O indipendenti da Plug and Play. Un driver WDM crea un DEVICE_OBJECT come destinazione per tali richieste, ma non lo collega allo stack di dispositivi Plug and Play. Per ottenere lo stesso risultato, un driver KMDF crea un oggetto dispositivo di controllo. Alcuni driver basati su framework usano oggetti dispositivo di controllo per implementare meccanismi di I/O "sideband" in modo che possano ricevere determinati tipi di richieste di I/O indipendentemente dallo stato del dispositivo.

Modello a oggetti

WDF supporta un modello a oggetti coerente in cui gli oggetti sono opachi per i driver, forniscono aree di contesto configurabili dal driver e fanno riferimento a un handle. Gli oggetti WDM sono oggetti a livello di sistema accessibili ai driver e a cui fanno riferimento i puntatori. Un driver che danneggia un oggetto WDM può danneggiare l'intero sistema. Il danneggiamento di un oggetto WDF non è solo più difficile, perché il framework convalida i dati forniti dal driver, ma causa anche problemi a livello di sistema molto meno spesso.

Per informazioni sulla convenzione di denominazione per gli oggetti KMDF, vedere Architettura WDF.

Il framework mantiene un conteggio dei riferimenti per ogni oggetto, che fornisce quindi un certo controllo sulla sua durata. Per ulteriori informazioni, vedere il Ciclo di vita dell'oggetto del framework .

Sebbene molti oggetti WDF corrispondano agli oggetti WDM, gli oggetti WDF supportano funzionalità che richiedono codice aggiuntivo in un driver WDM. Tutti gli oggetti WDF supportano aree di contesto di oggetti definibili driver in modo che un driver possa archiviare informazioni correlate a una particolare istanza di un oggetto con l'oggetto stesso. Anche gli oggetti tengono traccia dello stato. Ad esempio, gli oggetti WDFQUEUE sono più che un elenco di richieste di I/O; supportano diversi tipi di invio, sincronizzazione automatica con Plug and Play e richiesta di annullamento. Per gli oggetti WDFMEMORY, il conteggio dei riferimenti gestiti dal framework consente di evitare perdite di memoria e rilascio prematuro delle risorse.

Creazione di oggetti

I driver WDF seguono un modello regolare per creare tutti i tipi di oggetti:

  1. Inizializzare la struttura di configurazione per l'oggetto, se presente.
  2. Facoltativamente, inizializzare la struttura degli attributi per l'oggetto .
  3. Chiamare il metodo di creazione per creare l'oggetto .

La struttura di configurazione e la struttura degli attributi forniscono informazioni di base sull'oggetto e sul modo in cui il driver lo usa. Tutti i tipi di oggetto usano WDF_OBJECT_ATTRIBUTES come struttura degli attributi, ma la struttura di configurazione per ogni tipo di oggetto è diversa e alcuni oggetti non ne hanno uno. Ad esempio, esiste una struttura WDF_DRIVER_CONFIG ma non una struttura WDF_DEVICE_CONFIG.

La struttura di configurazione contiene puntatori a informazioni specifiche dell'oggetto, ad esempio le funzioni di callback degli eventi del driver per l'oggetto. Il driver compila questa struttura e quindi lo passa al framework quando chiama il metodo di creazione dell'oggetto. Ad esempio, una chiamata a WdfDriverCreate include un puntatore a una struttura WDF_DRIVER_CONFIG che contiene un puntatore alla funzione di callback EvtDriverDeviceAdd.

Il framework definisce le funzioni denominate WDF_Object_CONFIG_INIT per inizializzare le strutture di configurazione, dove Object rappresenta il nome del tipo di oggetto. La funzione WDF_OBJECT_ATTRIBUTES_INIT inizializza la struttura WDF_OBJECT_ATTRIBUTESdel driver.

Area contesto dell'oggetto

Ogni istanza di un oggetto può avere una o più aree di contesto oggetto. L'area di contesto dell'oggetto è un'area di archiviazione per i dati correlati a tale istanza specifica, ad esempio un oggetto evento allocato dal driver. Il driver determina le dimensioni e il layout dell'area del contesto dell'oggetto. Per un oggetto dispositivo, l'area del contesto dell'oggetto è l'equivalente dell'estensione del dispositivo WDM. Per informazioni sulla definizione e l'inizializzazione di un'area di contesto, vedere Framework Object Context Space.

Tipi IRP supportati

WDF supporta un subset di IRP di Windows. Per un riepilogo dei principali tipi IRP WDM e delle funzioni di callback degli eventi WDF corrispondenti, vedere WDM IRPs e funzioni di callback degli eventi WDF.

Anche se il driver riceve irP diversi da quelli elencati nella tabella, è possibile convertirlo in KMDF. KMDF fornisce un meccanismo attraverso il quale un driver può ricevere IRP WDM "non elaborati" e usare anche le funzionalità KMDF per altri tipi di IRP. Per altre informazioni, vedere Gestione degli IRP WDM all'esterno del framework.

Code di I/O

Quasi tutti i driver mettono in coda le richieste di I/O. I driver WDM usano in genere uno degli approcci seguenti:

  • Implementare una funzione StartIo e chiamare IoStartPacket e IoStartNextPacket per usare la coda dei dispositivi del sistema per le richieste di I/O.
  • Usare il IoCsqXxx o altre funzioni di gestione elenco per implementare le proprie code di I/O interne.
  • Usare le funzioni KeXxxDeviceQueue per inizializzare e gestire una coda protetta da un blocco attivo.

Un driver WDF crea un oggetto coda WDF (WDFQUEUE) per rappresentare una coda di I/O. L'oggetto coda WDF è simile a una coda annullabile in modo sicuro, ma offre funzionalità aggiuntive.

Quando si esegue la conversione di un driver WDM in WDF, è possibile usare il meccanismo di accodamento WDF indipendentemente dal meccanismo usato dal driver WDM. Per ulteriori informazioni sulle code, consultare Framework Queue Objects.

Sincronizzazione e concorrenza

I driver WDF traggono vantaggio da un supporto di sincronizzazione predefinito non disponibile per i driver WDM. Anche se questo supporto non significa che il driver può ignorare la concorrenza e l'accesso sincrono ai dati, i driver WDF richiedono tuttavia un minor numero di blocchi e meno codice di sincronizzazione rispetto ai driver WDM.

Per altre informazioni sulle funzionalità di sincronizzazione fornite dal framework, vedere Synchronization Techniques.

Installazione driver

Come i driver WDM, i driver KMDF e UMDF vengono installati usando i file INF. Tuttavia, l'installazione del driver WDF a volte richiede un co-programma di installazione del framework fornito con Windows Driver Kit (WDK). Il co-programma di installazione garantisce che nel sistema di destinazione sia presente una versione compatibile della libreria framework. Per informazioni sull'installazione, vedere Compilazione e caricamento di un driver WDF.