Initialisation des miniports virtuels
Un pilote intermédiaire initialise ses miniports virtuels une fois qu’il a ouvert avec succès un adaptateur miniport sous-jacent et qu’il est prêt à accepter les demandes et à envoyer sur ses miniports virtuels. Un pilote intermédiaire appelle NdisIMInitializeDeviceInstanceEx à partir de sa fonction ProtocolBindAdapterEx une ou plusieurs fois pour demander l’initialisation d’une ou plusieurs miniports virtuels.
Note Un pilote intermédiaire n’est pas nécessaire pour appeler NdisIMInitializeDeviceInstanceEx lorsqu’il ouvre un adaptateur miniport sous-jacent. Il n’est pas obligé d’avoir une relation un-à-un entre les miniports virtuels et les adaptateurs ouverts.
Définissez le paramètre DriverInstance de NdisIMInitializeDeviceInstanceEx sur le nom de l’appareil pour le miniport virtuel en cours d’initialisation. Le pilote intermédiaire obtient le nom de l’appareil à partir de la clé de Registre UpperBindings .
Pour un pilote intermédiaire MUX n-à-un qui couche plusieurs miniports virtuels sur une seule carte réseau physique, il doit y avoir un nom d’appareil pour chaque miniport virtuel. Le pilote intermédiaire MUX nécessite un objet de notification qui gère la liste des noms de périphériques de miniport virtuel. L’emplacement recommandé pour la liste est la clé de Registre UpperBindings . Dans ce cas, la clé de Registre UpperBindings est une entrée MULTI_SZ qui contient la liste des noms d’appareils. Le pilote intermédiaire MUX appelle NdisIMInitializeDeviceInstanceEx une fois pour chaque nom d’appareil spécifié dans la liste des noms d’appareil.
L’appel de NdisIMInitializeDeviceInstanceEx entraîne un appel à la fonction MiniportInitializeEx du pilote intermédiaire pour effectuer l’initialisation du miniport virtuel spécifié, à condition que NDIS reçoive une IRP_MN_START_DEVICE pour démarrer l’appareil. Si NDIS ne reçoit pas un tel IRP, NDIS n’appelle pas la fonction MiniportInitializeEx du pilote intermédiaire. L’appel à MiniportInitializeEx peut se produire ultérieurement et n’est donc pas nécessairement dans le contexte de l’appel à NdisIMInitializeDeviceInstanceEx. Si NDIS n’appelle jamais MiniportInitializeEx pour le miniport virtuel référencé dans un appel à NdisIMInitializeDeviceInstanceEx et que le pilote intermédiaire n’a plus besoin du miniport virtuel, le pilote intermédiaire doit appeler NdisIMCancelInitializeDeviceInstance pour annuler l’initialisation du miniport virtuel. Par exemple, supposons qu’un pilote intermédiaire crée un miniport virtuel en réponse à une liaison réussie à un miniport sous-jacent. Si cette liaison est supprimée avant que NDIS appelle MiniportInitializeEx, le pilote intermédiaire doit appeler NdisIMCancelInitializeDeviceInstance pour annuler l’initialisation du miniport.
MiniportInitializeEx doit allouer et initialiser une zone de contexte spécifique au miniport virtuel. Pour plus d’informations sur la spécification de la zone de contexte, consultez Initialisation d’un miniport virtuel.
Un pilote intermédiaire doit fonctionner comme un pilote désérialisé. Pour plus d’informations sur les pilotes désérialisés, consultez Pilotes miniport NDIS désérialisés.
Un pilote intermédiaire doit vérifier que les informations d’état qu’il gère sont correctement initialisées. Si le pilote a besoin de ressources liées à l’envoi, par exemple, de nouvelles structures NET_BUFFER_LIST pour les données réseau que MiniportSendNetBufferLists transmettront à la couche inférieure suivante, le pool de structures NET_BUFFER_LIST peut être alloué à ce stade.