Initialisation d’un pilote de protocole
Le système appelle la routine DriverEntry d’un pilote de protocole après avoir chargé le pilote. Les pilotes de protocole se chargent en tant que services système. Ils peuvent se charger à tout moment avant, pendant ou après le chargement des pilotes miniport.
Les pilotes de protocole allouent des ressources de pilote et inscrivent les fonctions ProtocolXxx dans DriverEntry. Cela inclut les clients CoNDIS et les gestionnaires d’appels autonomes. Pour inscrire ses fonctions ProtocolXxx auprès de NDIS, un pilote de protocole appelle la fonction NdisRegisterProtocolDriver .
DriverEntry retourne STATUS_SUCCESS, ou son NDIS_STATUS_SUCCESS équivalent, si le pilote inscrit en tant que pilote de protocole NDIS a réussi. Si DriverEntry échoue à l’initialisation en propageant une erreur status retournée par une fonction NdisXxx ou par une routine de prise en charge en mode noyau, le pilote ne reste pas chargé. DriverEntry doit s’exécuter de manière synchrone ; autrement dit, il ne peut pas retourner STATUS_PENDING ou son NDIS_STATUS_PENDING équivalent.
La fonction DriverEntry d’un pilote de protocole NDIS doit appeler la fonction NdisRegisterProtocolDriver . Pour inscrire les points d’entrée ProtocolXxx du pilote auprès de la bibliothèque NDIS, un pilote de protocole initialise une structure NDIS_PROTOCOL_DRIVER_CHARACTERISTICS et la transmet à NdisRegisterProtocolDriver.
Les pilotes qui appellent NdisRegisterProtocolDriver doivent être préparés pour un appel immédiat à l’une de leurs fonctions ProtocolXxx.
Les pilotes de protocole NDIS fournissent les fonctions ProtocolXxx suivantes, qui sont des versions mises à jour des fonctions que les pilotes hérités fournissent :
ProtocolCloseAdapterCompleteEx
Les pilotes de protocole NDIS fournissent les fonctions ProtocolXxx suivantes pour les opérations d’envoi et de réception :
ProtocolSendNetBufferListsComplete
Tous les types de pilotes de protocole NDIS doivent inscrire les fonctions ProtocolBindAdapterEx et ProtocolUnbindAdapterEx entièrement fonctionnelles pour prendre en charge Plug-and-Play (PnP). En général, une fonction DriverEntry doit appeler NdisRegisterProtocolDriver immédiatement avant de retourner le contrôle avec une valeur status de STATUS_SUCCESS ou NDIS_STATUS_SUCCESS.
Tout pilote de protocole qui exporte un ensemble de routines de pilotes en mode noyau standard en plus de ses fonctions ProtocolXxx définies par NDIS doit définir les points d’entrée de ces routines de pilote dans l’objet pilote donné qui est passé à sa fonction DriverEntry . Pour plus d’informations sur les fonctionnalités de la fonction DriverEntry d’un pilote de protocole, consultez Écriture d’une routine DriverEntry.
Si une tentative d’allocation des ressources dont le pilote a besoin pour effectuer des opérations d’E/S réseau échoue, DriverEntry doit libérer toutes les ressources qu’il a déjà allouées avant de retourner le contrôle avec un status autre que STATUS_SUCCESS ou NDIS_STATUS_SUCCESS.
Si une erreur se produit après un appel réussi à NdisRegisterProtocolDriver, le pilote doit appeler la fonction NdisDeregisterProtocolDriver avant le retour de DriverEntry .
Pour autoriser un pilote de protocole à configurer des services facultatifs, NDIS appelle la fonction ProtocolSetOptions dans le contexte de l’appel du pilote de protocole à NdisRegisterProtocolDriver. Pour plus d’informations sur les services facultatifs, consultez Configuration des services de pilote de protocole facultatif.
Les pilotes clients CoNDIS doivent appeler la fonction NdisSetOptionalHandlers à partir de la fonction ProtocolSetOptions . Le pilote initialise une structure NDIS_CO_CLIENT_OPTIONAL_HANDLERS et la transmet au paramètre OptionalHandlers de NdisSetOptionalHandlers.
Les gestionnaires d’appels autonomes CoNDIS doivent également appeler la fonction NdisSetOptionalHandlers à partir de la fonction ProtocolSetOptions . Le pilote initialise une structure NDIS_CO_CALL_MANAGER_OPTIONAL_HANDLERS et la transmet au paramètre OptionalHandlers de NdisSetOptionalHandlers.
Les mcm ne sont pas des pilotes de protocole. Par conséquent, ils doivent appeler la fonction NdisSetOptionalHandlers à partir de la fonction MiniportSetOptions . Le MCM initialise une structure NDIS_CO_CALL_MANAGER_OPTIONAL_HANDLERS et la transmet au paramètre OptionalHandlers de NdisSetOptionalHandlers.
Pour annuler l’inscription auprès de NDIS, un pilote de protocole appelle NdisDeregisterProtocolDriver à partir de sa routine Deload .
Pour effectuer des opérations de nettoyage avant la désinstallation d’un pilote de protocole, un pilote de protocole peut inscrire une fonction ProtocolUninstall . La fonction ProtocolUninstall est facultative. Par exemple, le bord inférieur du protocole d’un pilote intermédiaire peut nécessiter une fonction ProtocolUninstall . Le pilote intermédiaire peut libérer ses ressources de périphérie de protocole dans ProtocolUninstall avant que NDIS appelle sa fonction MiniportDriverUnload .