DispatchPnP Routines

La routine DispatchPnP d’un pilote prend en charge Plug-and-Play en gérant les IRP pour le code de la fonction E/S IRP_MJ_PNP. Le code de fonction de IRP_MJ_PNP est associé à plusieurs codes de fonction D/S mineurs (voir Plug-and-Play les IIP mineurs), dont certains doivent être gérés par tous les pilotes et d’autres peuvent être gérés éventuellement. Le gestionnaire PnP utilise ces codes de fonction mineurs pour diriger les pilotes vers le démarrage, l’arrêt et la suppression des appareils, et pour interroger les pilotes sur leurs appareils.

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

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

• Un pilote de fonction ou de filtre doit passer les IRP PnP au pilote suivant de la pile de périphériques, sauf si la fonction ou le pilote de filtre gère l’IRP et rencontre une défaillance (en raison de ressources insuffisantes, par exemple).

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

  Un pilote peut échouer une IRP s’il 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, il ne doit pas échouer à l’IRP. Il doit passer un tel IRP au pilote suivant sans modifier la status de l’IRP.

• Un pilote doit gérer certains IIP PnP et peut éventuellement en gérer d’autres.

  Chaque pilote PnP est requis pour gérer certains IIP, tels que les IRP_MN_REMOVE_DEVICE, et peut éventuellement en gérer d’autres. Pour plus d’informations sur les IIP requis et facultatifs pour chaque type de pilote (pilotes de fonction, pilotes de filtre et pilotes de bus), consultez Plug-and-Play les IRP mineurs.

  Un pilote peut échouer un IRP PnP requis avec un status d’erreur approprié, mais un pilote ne doit pas retourner STATUS_NOT_SUPPORTED pour un tel IRP.

• Si un pilote gère correctement un IRP PnP, il définit l’status IRP sur réussite. Il ne dépend pas d’un autre pilote dans la pile pour définir le status.

  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 IRP, un pilote non-bus peut être en mesure de s’appuyer sur son pilote de bus parent pour définir le status sur la réussite. Toutefois, il s’agit d’une pratique risquée. Par souci de cohérence et de robustesse, un pilote doit définir le status IRP sur la réussite pour chaque IRP PnP qu’il gère avec succès.

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

  Pour faire échouer un IRP comme IRP_MN_QUERY_STOP_DEVICE, un pilote définit Irp-IoStatus.Status> sur STATUS_UNSUCCESSFUL. Les valeurs de status d’erreur supplémentaires pour les autres IRP incluent les STATUS_INSUFFICIENT_RESOURCES et les STATUS_INVALID_DEVICE_STATE.

  Les pilotes ne définissent pas STATUS_NOT_SUPPORTED pour les irps qu’ils gèrent. Il s’agit de la status initiale définie par le gestionnaire PnP. Si une IRP est terminée avec cette status, cela signifie qu’aucun pilote de la pile n’a géré l’IRP ; tous les pilotes ont juste passé l’IRP au pilote suivant.

• Un pilote doit gérer un IRP PnP dans sa routine de distribution (sur le chemin de l’IRP vers le bas de la pile des appareils), dans une routine IoCompletion (sur la façon de sauvegarder la pile d’appareils de l’IRP) ou les deux, comme spécifié dans la page de référence pour l’IRP.

  Certains IIP PnP, tels que IRP_MN_REMOVE_DEVICE, doivent être gérés d’abord par le pilote en haut de la pile d’appareils, puis par chaque pilote inférieur suivant. D’autres, comme IRP_MN_START_DEVICE, doivent être gérés en premier par le pilote de bus parent. D’autres encore, comme IRP_MN_QUERY_CAPABILITIES, peuvent être gérés à la fois sur le chemin vers le bas de la pile de l’appareil et sur le chemin de la sauvegarde. Pour connaître les règles qui s’appliquent à chaque IRP PnP, consultez Plug-and-Play IP secondaires. Consultez Reporting PnP IRP Processing Until Lower Drivers Finish (Reporting PnP IRP Processing Until Lower Drivers Finish ) pour plus d’informations sur la gestion des IRP PnP qui doivent être traités en premier par le pilote de bus parent.

• Un pilote doit ajouter des informations à un IRP sur le chemin de l’IRP vers le bas de la pile de l’appareil et modifier ou supprimer des informations sur la marche arrière de l’IRP.

  Lors du retour d’informations en réponse à une requête IRP de requête PnP, un pilote doit suivre cette convention pour permettre aux informations ordonnées de passer par les pilotes en couches d’un appareil.

• Sauf dans le cas où il est explicitement documenté, un pilote ne doit pas dépendre de l’envoi d’adresses IP PnP dans un ordre particulier.

• Lorsqu’un pilote envoie un IRP PnP, il doit envoyer l’IRP au pilote supérieur de la pile de périphériques.

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