Gestion d’une demande d’alimentation définie
Un pilote intermédiaire doit gérer les demandes de définition de l’état de fonctionnement (état d’alimentation du périphérique réseau D0) et des états de veille (état d’alimentation de l’appareil réseau D1, D2 ou D3). Le pilote intermédiaire doit également conserver des variables d’état d’alimentation et un indicateur StandBy. Ces questions sont abordées plus loin dans cette rubrique.
Pour obtenir des exemples de gestion de l’alimentation du pilote intermédiaire, consultez l’exemple NDIS MUX Intermediate Driver and Notify Object Driver dans le référentiel d’exemples de pilotes Windows sur GitHub.
Gestion d’une demande d’alimentation définie sur un état de veille
Il existe deux cas où un pilote intermédiaire doit gérer une demande d’alimentation définie à un état de veille :
NDIS demande que le bord supérieur du miniport virtuel du pilote intermédiaire passe à un état de veille.
Le protocole de pilote intermédiaire en périphérie inférieure gère la transition du pilote miniport sous-jacent vers un état de veille lorsqu’il reçoit une notification d’événement Plug-and-Play (PnP).
Ces événements peuvent se produire dans n’importe quel ordre et un événement n’accompagne pas nécessairement l’autre.
Lorsque le miniport virtuel en haut du pilote intermédiaire reçoit une demande pour définir l’alimentation sur un état de veille, la séquence d’événements pour la gestion de la requête est la suivante :
NDIS appelle la fonction ProtocolNetPnPEvent de chaque pilote de protocole lié au miniport virtuel. L’appel à ProtocolNetPnPEvent spécifie un événement NetEventSetPower pour un état de veille. Les pilotes de protocole liés au pilote intermédiaire arrêtent l’envoi de données réseau et effectuent des requêtes OID au miniport virtuel du pilote intermédiaire. Le bord inférieur du protocole du pilote intermédiaire peut continuer à envoyer des données réseau et des requêtes jusqu’à ce que NDIS indique que le pilote miniport sous-jacent effectue la transition vers un état de veille.
NDIS interrompt les pilotes surlysants, puis le miniport virtuel après avoir émis l’événement NetEventSetPower . La raison spécifiée de la pause est une transition vers un état à faible alimentation. Pour plus d’informations sur la suspension d’un miniport virtuel, consultez Suspension d’un adaptateur.
Notez qu’aucune demande OID ne peut être envoyée au miniport virtuel alors qu’elle est dans un état de faible puissance, à l’exception de OID_PNP_SET_POWER.
NDIS émet une requête OID_PNP_SET_POWER au miniport virtuel du pilote intermédiaire. Le pilote intermédiaire accepte la requête en retournant NDIS_STATUS_SUCCESS. Le pilote intermédiaire ne doit pas propager la requête OID_PNP_SET_POWER au pilote miniport sous-jacent. Une fois que le pilote intermédiaire a terminé cette demande, il ne doit pas indiquer plus de données réseau reçues ni indiquer l’état, même s’il continue de recevoir des données réseau et des indications d’état du pilote miniport sous-jacent.
Lorsque le bord inférieur du protocole du pilote intermédiaire passe le pilote miniport sous-jacent à un état de veille, la séquence d’événements pour la gestion de la transition est la suivante :
NDIS appelle la fonction ProtocolNetPnPEvent du protocole de pilote intermédiaire en périphérie inférieure. L’appel à ProtocolNetPnPEvent spécifie un événement NetEventSetPower pour un état de veille. Le pilote intermédiaire doit arrêter l’envoi de données réseau et effectuer des requêtes OID au pilote miniport sous-jacent. S’il existe des demandes ou des envois en attente, le pilote intermédiaire doit retourner NDIS_STATUS_PENDING de l’appel à ProtocolNetPnPEvent. Le pilote intermédiaire appelle NdisCompleteNetPnPEvent pour terminer l’appel à ProtocolNetPnPEvent. Le bord du protocole d’un pilote intermédiaire peut toujours obtenir les indications de paquet et d’état reçus du pilote miniport sous-jacent. Les données réseau reçues peuvent être ignorées. Si l’implémentation d’un pilote intermédiaire dépend de la surveillance de l’état du pilote miniport sous-jacent, les indications d’état doivent toujours être surveillées.
NDIS suspend le bord du protocole du pilote intermédiaire, puis suspend l’adaptateur miniport sous-jacent après avoir émis l’événement NetEventSetPower . La raison spécifiée de la pause est une transition vers un état à faible alimentation. Pour plus d’informations sur la suspension d’une liaison de protocole, consultez Suspension d’une liaison.
Notez qu’aucune demande OID ne peut être envoyée à l’adaptateur miniport sous-jacent alors qu’elle est dans un état de faible alimentation, à l’exception de OID_PNP_SET_POWER.
NDIS émet une requête OID_PNP_SET_POWER au pilote miniport sous-jacent. Toutefois, si le pilote miniport sous-jacent ne prend pas en charge la gestion de l’alimentation, il sera arrêté. Dans ce cas, même si NDIS arrête le pilote miniport sous-jacent, il ne demande pas au protocole de pilote intermédiaire de se dissocier du pilote miniport sous-jacent et de la carte réseau. Une fois que le pilote miniport sous-jacent a réussi à traiter l’OID (ou que le pilote miniport est arrêté), il n’indique pas plus de données réseau ou d’état.
Gestion d’une demande d’alimentation définie sur l’état de fonctionnement
Il existe deux cas où un pilote intermédiaire gère une demande d’alimentation définie sur l’état de fonctionnement :
NDIS demande que le bord supérieur du miniport virtuel du pilote intermédiaire passe à l’état de travail.
Le protocole de pilote intermédiaire de périphérie inférieure gère la transition du pilote miniport sous-jacent vers l’état de travail, lorsqu’il reçoit une notification d’événement Plug-and-Play (PnP).
Ces événements peuvent se produire dans n’importe quel ordre et un événement n’accompagne pas nécessairement l’autre.
Lorsque le bord supérieur du miniport virtuel du pilote intermédiaire reçoit une demande pour définir l’alimentation sur un état de fonctionnement, la séquence d’événements pour la gestion de la requête est la suivante :
NDIS émet une OID_PNP_SET_POWER au miniport virtuel du pilote intermédiaire. Le pilote intermédiaire retourne NDIS_STATUS_SUCCESS à la demande d’alimentation définie. Le pilote intermédiaire ne doit pas propager la requête OID_PNP_SET_POWER au pilote miniport sous-jacent.
NDIS redémarre le miniport virtuel, puis redémarre les pilotes surlysants après avoir émis l’OID de l’alimentation définie. Pour plus d’informations sur le redémarrage d’un miniport virtuel, consultez Démarrage d’une carte.
NDIS appelle la fonction ProtocolNetPnPEvent des pilotes de protocole overlying. L’appel à ProtocolNetPnPEvent spécifie un événement NetEventSetPower pour définir l’état de travail (D0). Les pilotes de protocole lié peuvent commencer à envoyer des données réseau au miniport virtuel du pilote intermédiaire.
Lorsque le bord inférieur du protocole du pilote intermédiaire passe le pilote miniport sous-jacent à un état de travail, la séquence d’événements pour la gestion de la transition est la suivante :
NDIS émet une OID_PNP_SET_POWER au pilote miniport sous-jacent ou appelle son gestionnaire MiniportInitializeEx si le pilote miniport sous-jacent a été arrêté.
NDIS redémarre le pilote miniport sous-jacent, puis le bord du protocole du NDIS intermédiaire et l’adaptateur miniport sous-jacent après avoir émis l’OID. Pour plus d’informations sur la suspension d’une liaison de protocole, consultez Redémarrage d’une liaison.
NDIS appelle la fonction ProtocolNetPnPEvent du pilote intermédiaire. L’appel à ProtocolNetPnPEvent spécifie un événement NetEventSetPower pour définir l’état de travail (D0). Le pilote intermédiaire peut commencer à envoyer des données réseau au pilote miniport sous-jacent.
États d’alimentation et indicateur de secours
Le pilote intermédiaire doit conserver une variable d’état d’alimentation distincte pour chaque instance de miniport virtuelle et pour chaque pilote miniport sous-jacent auquel le pilote est lié. Le pilote intermédiaire doit également conserver un indicateur StandingBy pour chaque miniport virtuel qui est :
Défini sur TRUE lorsque l’état d’alimentation de la miniport virtuelle ou du pilote miniport sous-jacent quitte D0.
Définissez la valeur FALSE lorsque l’état d’alimentation de la miniport virtuelle ou du pilote miniport sous-jacent retourne à D0.
Remarque Pour les pilotes intermédiaires MUX, il peut y avoir plusieurs miniports virtuels associés à un pilote miniport sous-jacent ou plusieurs miniports sous-jacents associés à chaque miniport virtuel. Lorsque l’état d’alimentation de n’importe quel adaptateur miniport change, le comportement de tous les miniports associés est également affecté. La façon dont le comportement est affecté est spécifique à l’implémentation. Par exemple, un pilote qui implémente une solution de basculement d’équilibrage de charge (LBFO) peut ne pas désactiver les miniports virtuels lorsqu’un seul pilote miniport sous-jacent est désactivé. Toutefois, une implémentation de pilote qui dépend de tous les pilotes miniports sous-jacents nécessiterait la désactivation des miniports virtuels quand un pilote miniport sous-jacent est désactivé.
Le pilote intermédiaire doit utiliser l’indicateur StandingBy et les variables d’état d’alimentation lors du traitement des demandes comme suit :
La fonction MiniportSendNetBufferLists du pilote doit échouer, sauf si le miniport virtuel et son adaptateur miniport sous-jacent sont tous les deux dans D0.
La fonction MiniportOidRequest du pilote doit toujours réussir OID_PNP_QUERY_POWER pour s’assurer que le pilote reçoit les demandes de OID_PNP_SET_POWER suivantes.
La fonction MiniportOidRequest du pilote doit échouer si le miniport virtuel n’est pas dans D0 ou si StandingBy a la valeur TRUE. Sinon, il doit mettre en file d’attente une seule requête si le pilote miniport sous-jacent n’est pas dans D0. Une requête mise en file d’attente doit être traitée lorsque l’état du pilote miniport sous-jacent devient D0.
Le miniport virtuel du pilote intermédiaire doit signaler l’état uniquement si le pilote miniport sous-jacent et le miniport virtuel se trouvent dans D0.