Conversione di driver miniport NDIS in NetAdapterCx
Questa pagina descrive come convertire un driver miniport NDIS 6.x in un driver client NetAdapterCx.
Per informazioni generali su WDF, vedere la Guida allo sviluppo di driver WDF.
Impostazioni di compilazione
Aprire il progetto di driver miniport NDIS esistente in Visual Studio e seguire questa procedura per convertirlo in un progetto KMDF.
Passare innanzitutto a Proprietà di configurazione-Driver> Impostazioni-Driver> Model e verificare che Il tipo di driver sia impostato su KMDF e che kmDF Version Major e KMDF Version Minor siano entrambi vuoti.
Nelle proprietà del progetto aprire Driver Impostazioni-Network> Adapter Driver e impostare Collegamento all'estensione della classe scheda di rete su Sì.
- Se il driver convertito chiamerà comunque le API NDIS, continuare a collegarsi
ndis.lib
a .
- Se il driver convertito chiamerà comunque le API NDIS, continuare a collegarsi
Rimuovere le macro del preprocessore NDIS, ad esempio
NDIS650_MINIPORT=1
.Aggiungere le intestazioni seguenti a ogni file di origine (o all'intestazione comune/precompilata):
#include <ntddk.h> #include <wdf.h> #include <netadaptercx.h>
Aggiungere decorazioni WDF standard all'INF:
[Yourdriver.Wdf] KmdfService = Yourdriverservice, Yourdriver.wdfsect [Yourdriver.wdfsect] KmdfLibraryVersion = <insert here>
Aggiungere nuove parole chiave di rete necessarie alla sezione NT di INF:
*If Connessione orPresent
*Connessione ionType
*DirectionType
*AccessType
*HardwareLoopback
Per altre informazioni su queste parole chiave e un esempio, vedere File INF per i driver client NetAdapterCx.
Inizializzazione del driver
Rimuovere la chiamata a NdisMRegisterMiniportDriver da DriverEntry e aggiungere quanto segue:
WDF_DRIVER_CONFIG_INIT(&config, EvtDriverDeviceAdd);
status = WdfDriverCreate(. . . );
if (!NT_SUCCESS(status)) {
return status;
}
Se è impostato, rimuovere il flag WdfDriverInitNoDispatchOverride dalla chiamata a WdfDriverCreate.
DriverUnload è una routine facoltativa per un driver client di rete WDF, quindi è possibile rimuoverlo se lo si desidera. Non chiamare NdisMDeregisterMiniportDriver da DriverUnload.
Inizializzazione del dispositivo
Successivamente, si distribuirà il codice da MiniportInitializeEx nei gestori di callback eventi WDF appropriati, diversi dei quali sono facoltativi. Per informazioni dettagliate sulla sequenza di callback, vedere Sequenza di power-up per un driver client WDF della scheda di rete.
I metodi equivalenti a NdisMSetMiniportAttributes verranno chiamati quando si avvia l'adattatore net, ma prima di chiamare NetAdapterStart. Tuttavia, invece di chiamare una routine con una struttura di NDIS_MINIPORT_ADAPTER_ATTRIBUTES generica, il driver client chiama funzioni diverse per impostare diversi tipi di funzionalità.
Per informazioni sui callback che dovrai fornire e quando avviare una scheda net, vedi Inizializzazione di dispositivi e adattatori.
Lettura della configurazione dal Registro di sistema
Sostituire quindi le chiamate a NdisOpenConfigurationEx e alle funzioni correlate con i NetConfiguration*
metodi . I NetConfiguration*
metodi sono simili alle Ndis*Configuration*
funzioni e non è necessario ristrutturare il codice.
Per altre informazioni, vedere Accesso alle informazioni di configurazione.
Ricezione di codici di controllo I/O (IOCTLs) dalla modalità utente
Leggere questa sezione se il driver NDIS chiama NdisRegisterDeviceEx, una routine usata per creare un oggetto dispositivo di controllo (CDO) per ricevere IOCTLs dalla modalità utente.
Ecco due modi per eseguire questa operazione nel driver del client di rete WDF.
La porta più semplice consiste nel creare un oggetto dispositivo di controllo chiamando WdfControlDeviceInitAllocate dal callback EVT_WDF_DRIVER_DEVICE_ADD del client. Per altre info, vedi Uso di oggetti dispositivo di controllo.
Tuttavia, la soluzione consigliata consiste nel creare un'interfaccia del dispositivo, come descritto in Uso delle interfacce dispositivo.
Completamento dell'inizializzazione del dispositivo
A questo punto in EVT_WDF_DRIVER_DEVICE_ADD, puoi eseguire qualsiasi altra operazione che desideri inizializzare il dispositivo, ad esempio l'allocazione di interrupt.
Gestione delle notifiche di modifica dello stato di alimentazione
Un driver client WDF non riceve OID_PNP_edizione Standard T_POWER per le modifiche dello stato di alimentazione.
Un client WDF registra invece le funzioni di callback facoltative per ricevere notifiche di modifica dello stato di alimentazione. Per una panoramica, vedere Supporto di PnP e risparmio energia nei driver di funzione.
In genere, il codice nel gestore OID_PNP_edizione Standard T_POWER passa a EVT_WDF_DEVICE_D0_EXIT e EVT_WDF_DEVICE_D0_ENTRY.
Poiché la macchina a stati di alimentazione WDF è leggermente diversa, potrebbe essere necessario apportare modifiche secondarie al codice.
In particolare, nella sua funzione di callback MiniportInitializeEx , un driver miniport NDIS esegue attività di inizializzazione una tantum, nonché lavorare per portare il dispositivo allo stato D0. Ripete quindi il lavoro per passare a D0 nel gestore OID_PNP_edizione Standard T_POWER.
Al contrario, un client WDF esegue attività di inizializzazione una tantum nei callback degli eventi prima di EVT_WDF_DEVICE_D0_ENTRY, durante il quale il dispositivo si trova in uno stato a basso consumo. Quindi esegue il lavoro per passare a D0 in EVT_WDF_DEVICE_D0_ENTRY.
Per riepilogare, in WDF si inserisce il codice "vai a D0" in un'unica posizione, anziché due.
Per informazioni dettagliate sulla sequenza di callback, vedere Sequenza di Power-Up per un driver client NetAdapterCx.
Esecuzione di query e impostazione delle funzionalità di risparmio energia
Analogamente, un driver client WDF non riceve OID_PM_PARAMETERS per eseguire query o impostare le funzionalità hardware di risparmio energia della scheda di rete.
Il driver esegue invece una query sulla configurazione di riattivazione LAN (WoL) necessaria dall'oggetto NETPOWER edizione Standard TTINGS. Per altre informazioni, vedere Configurazione del risparmio energia.
I flag effettivi restituiti hanno la stessa semantica di un miniport NDIS 6, quindi non è necessario apportare modifiche profonde alla logica. La differenza principale è che ora è possibile eseguire query su questi flag durante la sequenza di risparmio di energia. Vedere Sequenza di power-down per un driver client NetAdapterCx.
Dopo aver spostato questo codice, è possibile eliminare i gestori OID per OID_PNP_edizione Standard T_POWER e OID_PM_PARAMETERS.
Poiché il framework NetAdapter mantiene il dispositivo in D0 mentre l'host usa l'interfaccia di rete, il client in genere non implementa la logica di alimentazione; il comportamento di alimentazione NetAdapter predefinito è sufficiente.
Percorso dati
Il modello di programmazione del percorso dati è cambiato in modo significativo. Ecco alcune differenze principali:
- Nel modello NetAdapter il traffico di rete non è più per scheda, come in NDIS, ma piuttosto per ogni coda WDF. Vedere Creazione di code di I/O.
- Invece di NET_BUFFER_LIST e pool di NET_BUFFER, NetAdapterCx introduce un buffer circolare costituito da pacchetti net, che eseguono il mapping a NDIS come indicato di seguito:
- Un NET_PACKET è simile a un NET_BUFFER_LIST + NET_BUFFER.
- Un NET_PACKET_FRAGMENT è simile a un elenco di descrittori di memoria (MDL). Ogni NET_PACKET ha uno o più di questi.
- Per informazioni dettagliate sulle strutture di sostituzione e su come usarle, vedere Descrittori di pacchetti ed estensioni.
- In NDIS 6.x, il miniport deve gestire la semantica di avvio e pausa. Nel modello NetAdapterCx questo non è più il caso.
- Il callback EVT_RXQUEUE_ADVANCE è simile a MINIPORT_RETURN_NET_BUFFER_LISTS in NDIS 6.x.
- Il callback EVT_TXQUEUE_ADVANCE è simile a MINIPORT_edizione Standard ND_NET_BUFFER_LISTS in NDIS 6.x.
Rimozione del dispositivo
La rimozione del dispositivo per un driver di scheda di interfaccia di rete WDF è identica a quella di qualsiasi altro driver di dispositivo WDF, senza alcuna elaborazione specifica di rete necessaria. Il percorso dei dati di rete viene arrestato per primo, seguito dal dispositivo WDF. Per informazioni sull'arresto di WDF, vedi Un utente scollega un dispositivo.
È probabile che il gestore MiniportHaltEx venga distribuito tra EVT_WDF_DEVICE_D0_EXIT e EVT_WDF_DEVICE_RELEA edizione Standard_HARDWARE.
Il client WDF non deve eliminare netadapter o le code del percorso dati create. WDF elimina automaticamente questi oggetti.
È possibile eliminare MiniportShutdownEx, MiniportResetEx e MiniportCheckForHangEx. Questi callback non sono più supportati.
Equivalenti di funzioni NDIS-WDF
La maggior parte delle NdisXxx
funzioni può essere sostituita con un equivalente WDF. In generale, si noterebbe che sono necessarie pochissime funzionalità importate da NDIS.SYS
.
Per un elenco degli equivalenti di funzioni, vedere Equivalenti di funzioni NDIS-WDF.
Debug
Vedere Debug di un driver client NetAdapterCx.
L'estensione del debugger !ndiskd.netadapter mostra risultati simili a quello visualizzato da !ndiskd.miniport per un driver NDIS 6.
Conclusione
Usando i passaggi descritti in questo argomento, è necessario disporre di un driver funzionante che avvia e arresta il dispositivo.
Nota: NetAdapterCx attualmente non supporta l'avvio iSCSI.