Routines DispatchPnP

La routine DispatchPnP d’un pilote prend en charge Plug and Play en gérant les IRP pour le code de fonction E/S IRP_MJ_PNP. Associés au code de fonction IRP_MJ_PNP se trouvent plusieurs codes de fonction d’E/S mineurs (voir Plug and Play Minor IRPs), dont certains doivent être gérés par tous les pilotes, tandis que d'autres peuvent être pris en charge facultativement. Le gestionnaire PnP utilise ces codes de fonction secondaires pour diriger les pilotes pour démarrer, arrêter et supprimer des appareils et interroger les pilotes sur leurs appareils.

Tous les pilotes d’un appareil doivent avoir la possibilité de gérer les IRP PnP pour l’appareil, sauf dans quelques cas où un pilote de fonction ou de filtre est autorisé à rejeter l’IRP.

La routine DispatchPnP de chaque pilote doit respecter les règles suivantes :

• Une fonction ou un pilote de filtre doit transmettre les PnP IRPs au pilote suivant dans la pile de périphériques, sauf si le pilote de fonction ou de filtre les gère et rencontre un échec (en raison de ressources insuffisantes, par exemple).

  Tous les pilotes d’un appareil doivent avoir la possibilité de gérer les irps PnP pour l’appareil, sauf si l’un des pilotes rencontre une erreur. Le gestionnaire PnP envoie des IRPs au pilote supérieur dans une pile d’appareils. Les pilotes de fonction et de filtre passent l’IRP au pilote suivant, et le pilote de bus parent termine l’IRP. Pour plus d’informations, consultez Comment passer les IRPs PnP dans la pile de périphériques.

  Un pilote peut échouer à traiter un IRP si iI tente de gérer l’IRP et rencontre une erreur (par exemple, des ressources insuffisantes). Si un pilote reçoit un IRP avec un code qu’il ne gère pas, le pilote ne doit pas rejeter l’IRP. Il doit passer un tel IRP au pilote suivant sans modifier l’état de l’IRP.

• Un pilote doit gérer certains IRP PnP et peut choisir de gérer d'autres.

  Chaque pilote PnP est requis pour gérer certains IRPs, tels que IRP_MN_REMOVE_DEVICE, et peut éventuellement gérer d’autres utilisateurs. Voir Plug and Play Minor IRPs pour plus d'informations sur les IRP requises et facultatives pour chaque type de pilote (pilotes de fonction, pilotes de filtre et pilotes de bus).

  Un pilote peut rejeter un IRP PnP requis avec un état d'erreur approprié, mais il ne doit pas retourner STATUS_NOT_SUPPORTED pour ce type d'IRP.

• Si un pilote gère correctement un IRP PnP, il définit le statut de l’IRP sur 'réussi'. Il ne dépend pas d’un autre pilote de la pile pour définir l’état.

  Un pilote définit Irp-IoStatus.Status> sur STATUS_SUCCESS pour informer le gestionnaire PnP que le pilote a géré l’IRP avec succès. Pour certains IRPs, un pilote non-bus peut être en mesure de s’appuyer sur son pilote de bus parent pour définir l’état sur 'réussi'. Toutefois, il s’agit d’une pratique risquée. Pour assurer la cohérence et la robustesse, un pilote doit définir l'état de l'IRP sur réussite pour chaque IRP PnP qu'il gère correctement.

• Si un pilote échoue à un IRP, le pilote termine l’IRP avec un état d’erreur et ne transmet pas le IRP au pilote suivant.

  Pour échouer un IRP comme IRP_MN_QUERY_STOP_DEVICE, un pilote définit Irp-IoStatus.Status> sur STATUS_UNSUCCESSFUL. D’autres valeurs d’état d’erreur pour d’autres IRP incluent STATUS_INSUFFICIENT_RESOURCES et STATUS_INVALID_DEVICE_STATE.

  Les pilotes ne définissent pas STATUS_NOT_SUPPORTED pour les IRP qu'ils traitent. Il s’agit de l’état initial défini par le gestionnaire PnP. Si un IRP est terminé avec ce statut, cela signifie qu’aucun pilote de la pile n’a géré l’IRP ; tous les pilotes ont simplement passé l’IRP au pilote suivant.

• Un pilote doit gérer un IRP PnP dans sa routine de distribution (lorsque l'IRP descend la pile d'appareils), dans une routine IoCompletion (lorsque l'IRP remonte la pile d'appareils), ou les deux, comme spécifié dans la page de référence pour l’IRP.

  Certains irps PnP, tels que IRP_MN_REMOVE_DEVICE, doivent d’abord être gérés par le pilote en haut de la pile de périphériques, puis par chaque pilote inférieur suivant. D’autres, comme IRP_MN_START_DEVICE, doivent être gérées en premier par le pilote de bus parent. D’autres encore, telles que IRP_MN_QUERY_CAPABILITIES, peuvent être gérées à la fois en descendant et en remontant la pile de l’appareil. Pour connaître les règles qui s’appliquent à chaque IRP PnP, consultez Plug-and-Play Minor IRPs . Consultez Postponing PnP IRP Processing Until Lower Drivers Finish pour des informations sur le traitement des IRP PnP qui doivent d'abord être traitées par le pilote du bus parent.

• Un pilote doit ajouter des informations à un IRP pendant sa descente dans la pile de périphériques et modifier ou supprimer des informations lors de sa remontée.

  Lorsque des informations sont retournées en réponse à une requête IRP PnP, un pilote doit suivre cette convention pour permettre une transmission ordonnée des informations par les pilotes empilés d'un appareil.

• À l'exception des cas explicitement documentés, un pilote ne doit pas dépendre des IRPs PnP envoyés dans un ordre particulier.

• Lorsqu’un pilote envoie un IRP PnP, il doit envoyer l’IRP au pilote supérieur dans la pile d’appareils.

  La plupart des irps PnP sont envoyées par le gestionnaire PnP, mais certaines peuvent être envoyées par des pilotes (par exemple, IRP_MN_QUERY_INTERFACE). Un pilote doit envoyer un IRP PnP au pilote en haut de la pile d’appareils. Appelez IoGetAttachedDeviceReference pour obtenir un pointeur vers l’objet de périphérique pour le pilote au sommet de la pile de périphériques.