Share via

Portage de pilotes miniport NDIS vers NetAdapterCx

  • Article

Cette page explique comment convertir un pilote miniport NDIS 6.x en pilote client NetAdapterCx.

Pour obtenir des informations générales sur WDF, consultez le Guide de développement des pilotes WDF.

Paramètres de compilation

Ouvrez votre projet de pilote miniport NDIS existant dans Visual Studio et procédez comme suit pour le convertir en projet KMDF.

  1. Tout d’abord, accédez à Configuration Properties-Driver> Paramètres-Driver> Model et vérifiez que le type de pilote est défini sur KMDF, et que kmDF Version majeure et KMDF Version Mineure sont tous deux vides.

  2. Dans les propriétés du projet, ouvrez Driver Paramètres-Network> Adapter Driver et définissez Link to the Network Adapter Class Extension to Yes.

    • Si votre pilote converti appelle toujours les API NDIS, continuez à établir une liaison avec ndis.lib.

  3. Supprimez les macros de préprocesseur NDIS, comme NDIS650_MINIPORT=1.

  4. Ajoutez les en-têtes suivants à chaque fichier source (ou à votre en-tête commun/précompilé) :

    #include <ntddk.h>
#include <wdf.h>
#include <netadaptercx.h>

  5. Ajoutez des décorations WDF standard à votre INF :

    [Yourdriver.Wdf]
KmdfService = Yourdriverservice, Yourdriver.wdfsect

[Yourdriver.wdfsect]
KmdfLibraryVersion = <insert here>

  6. Ajoutez de nouvelles mot clé réseau requises à la section NT de votre INF :

    • *If Connecter orPresent

    • *Connecter ionType

    • *DirectionType

    • *AccessType

    • *HardwareLoopback

      Pour plus d’informations sur ces mot clé et un exemple, consultez les fichiers INF pour les pilotes clients NetAdapterCx.

Initialisation du pilote

Supprimez l’appel à NdisMRegisterMiniportDriver de DriverEntry et ajoutez les éléments suivants :

WDF_DRIVER_CONFIG_INIT(&config, EvtDriverDeviceAdd);
status = WdfDriverCreate(. . . );
if (!NT_SUCCESS(status)) {
  return status;
}

S’il est défini, supprimez l’indicateur WdfDriverInitNoDispatchOverride de l’appel à WdfDriverCreate.

DriverUnload est une routine facultative pour un pilote client de mise en réseau WDF. Vous pouvez donc le supprimer si vous le souhaitez. NdisMDeregisterMiniportDriver n’appelez pas DriverUnload.

Initialisation de l’appareil

Ensuite, vous allez distribuer du code à partir de MiniportInitializeEx dans les gestionnaires de rappel d’événements WDF appropriés, dont plusieurs sont facultatifs. Pour plus d’informations sur la séquence de rappel, consultez Séquence d’alimentation pour un pilote client WDF de carte réseau.

Vous allez appeler les méthodes équivalentes à NdisMSetMiniportAttributes lorsque vous démarrez votre adaptateur net, mais avant d’appeler NetAdapterStart. Toutefois, au lieu d’appeler une routine avec une structure de NDIS_MINIPORT_ADAPTER_ATTRIBUTES générique, le pilote client appelle différentes fonctions pour définir différents types de fonctionnalités.

Pour plus d’informations sur les rappels, vous devez fournir et quand démarrer une carte réseau, consultez l’initialisation de l’appareil et de l’adaptateur.

Lecture de la configuration à partir du Registre

Ensuite, remplacez les appels à NdisOpenConfigurationEx et les fonctions associées par les NetConfiguration* méthodes. Les NetConfiguration* méthodes sont similaires aux Ndis*Configuration* fonctions, et vous n’aurez pas besoin de restructurer votre code.

Pour plus d’informations, consultez Accès aux informations de configuration.

Réception de codes de contrôle d’E/S (IOCTL) à partir du mode utilisateur

Lisez cette section si votre pilote NDIS appelle NdisRegisterDeviceEx, une routine utilisée pour créer un objet de périphérique de contrôle (CDO) pour recevoir des IOCTLs à partir du mode utilisateur.

Voici deux façons de procéder dans votre pilote client de mise en réseau WDF.

Le port le plus simple consiste à créer un objet d’appareil de contrôle en appelant WdfControlDeviceInitAllocate à partir du rappel EVT_WDF_DRIVER_DEVICE_ADD du client. Pour plus d’informations, consultez Utilisation des objets d’appareil de contrôle.

Toutefois, la solution recommandée consiste à créer une interface d’appareil, comme décrit dans Utilisation des interfaces d’appareil.

Fin de l’initialisation de l’appareil

À ce stade de EVT_WDF_DRIVER_DEVICE_ADD, vous pouvez effectuer tout autre chose que vous souhaitez initialiser votre appareil, comme l’allocation d’interruptions.

Gestion des notifications de modification de l’état d’alimentation

Un pilote client WDF ne reçoit pas de OID_PNP_SET_POWER pour les modifications d’état d’alimentation.

Au lieu de cela, un client WDF inscrit des fonctions de rappel facultatives pour recevoir des notifications de modification de l’état d’alimentation. Pour obtenir une vue d’ensemble, consultez Prise en charge de PnP et de gestion de l’alimentation dans les pilotes de fonction.

En règle générale, le code de votre gestionnaire de OID_PNP_SET_POWER passe à EVT_WDF_DEVICE_D0_EXIT et EVT_WDF_DEVICE_D0_ENTRY.

Étant donné que la machine d’état de l’alimentation WDF est légèrement différente, vous devrez peut-être apporter des modifications mineures au code.

Plus précisément, dans sa fonction de rappel MiniportInitializeEx , un pilote miniport NDIS effectue des tâches d’initialisation à usage unique, ainsi que pour amener l’appareil à l’état D0. Ensuite, il répète le travail pour accéder à D0 dans son gestionnaire OID_PNP_SET_POWER.

En revanche, un client WDF effectue des tâches d’initialisation ponctuelles dans les rappels d’événements avant EVT_WDF_DEVICE_D0_ENTRY, pendant laquelle l’appareil est dans un état à faible alimentation. Ensuite, il fait le travail d’aller à D0 dans EVT_WDF_DEVICE_D0_ENTRY.

Pour résumer, dans WDF, vous placez votre code « aller à D0 » au lieu de deux.

Pour plus d’informations sur la séquence de rappel, consultez la séquence Power-Up pour un pilote client NetAdapterCx.

Interrogation et définition des fonctionnalités de gestion de l’alimentation

De même, un pilote client WDF ne reçoit pas de OID_PM_PARAMETERS pour interroger ou définir les fonctionnalités matérielles de gestion de l’alimentation de la carte réseau.

Au lieu de cela, le pilote interroge la configuration woL (Wake-on-LAN) nécessaire à partir de l’objet NETPOWERSETTINGS. Pour plus d’informations, consultez Configuration de la gestion de l’alimentation.

Les indicateurs réels que vous revenez ont la même sémantique que pour un miniport NDIS 6. Vous n’avez donc pas besoin d’apporter de modifications approfondies à la logique. La principale différence est que vous pouvez désormais interroger ces indicateurs pendant la séquence de mise sous tension. Consultez la séquence de mise hors tension d’un pilote client NetAdapterCx.

Une fois que vous avez déplacé ce code, vous pouvez supprimer vos gestionnaires OID pour OID_PNP_SET_POWER et OID_PM_PARAMETERS.

Étant donné que le framework NetAdapter conserve votre appareil au niveau D0 pendant que l’hôte utilise l’interface réseau, le client n’implémente généralement pas la logique d’alimentation ; le comportement d’alimentation NetAdapter par défaut est suffisant.

Chemin d’accès aux données

Le modèle de programmation du chemin de données a changé de manière significative. Voici quelques différences clés :

Retrait d’un appareil

La suppression d’un périphérique pour un pilote de carte réseau WDF est la même que dans tout autre pilote de périphérique WDF, sans traitement spécifique à la mise en réseau requise. Le chemin des données réseau s’arrête en premier, suivi de l’appareil WDF. Pour plus d’informations sur l’arrêt WDF, voir Un utilisateur déconnecte un appareil.

Votre gestionnaire MiniportHaltEx sera probablement distribué entre EVT_WDF_DEVICE_D0_EXIT et EVT_WDF_DEVICE_RELEASE_HARDWARE.

Le client WDF n’a pas besoin de supprimer NetAdapter ou l’une des files d’attente de chemins de données qu’il a créées. WDF supprime automatiquement ces objets.

Vous pouvez supprimer MiniportShutdownEx, MiniportResetEx et MiniportCheckForHangEx. Ces rappels ne sont plus pris en charge.

Équivalents de la fonction NDIS-WDF

La plupart des NdisXxx fonctions peuvent être remplacées par un équivalent WDF. En général, vous devez trouver que vous avez besoin de très peu de fonctionnalités importées à partir de NDIS.SYS.

Pour obtenir la liste des équivalents de fonction, consultez les équivalents de fonction NDIS-WDF.

Débogage

Consultez Débogage d’un pilote client NetAdapterCx.

L’extension de débogueur !ndiskd.netadapter affiche des résultats similaires à ce que !ndiskd.miniport affiche pour un pilote NDIS 6.

Conclusion

À l’aide des étapes décrites dans cette rubrique, vous devez disposer d’un pilote de travail qui démarre et arrête votre appareil.

Remarque : NetAdapterCx ne prend actuellement pas en charge le démarrage iSCSI.