Irps de mise en file d’attente et de retrait de la file d’attente

Étant donné que le gestionnaire d’E/S prend en charge les E/S asynchrones au sein d’un système multitâche et multithread, les demandes d’E/S adressées à un appareil peuvent être effectuées plus rapidement que son pilote ne peut les traiter jusqu’à leur achèvement, en particulier sur les ordinateurs multiprocesseurs. Par conséquent, les irps liés à un appareil particulier doivent être mis en file d’attente dans le pilote lorsque son appareil est déjà occupé à traiter un autre IRP.

Par conséquent, un pilote de niveau inférieur nécessite l’une des opérations suivantes :

• Une routine StartIo , que le gestionnaire d’E/S appelle pour démarrer les opérations d’E/S pour les IRP que le pilote a mis en file d’attente dans une file d’attente IRP fournie par le système (voir IoStartPacket).

• Mécanisme interne de mise en file d’attente et de retrait de file d’attente IRP, que le pilote utilise pour gérer les IRP qui arrivent plus rapidement qu’il ne peut les satisfaire. Les pilotes peuvent utiliser des files d’attente d’appareils, des files d’attente verrouillées ou des files d’attente cancel-safe. Pour plus d’informations, consultez Files d’attente IRP gérées par le pilote.

Seul un pilote de périphérique de niveau inférieur capable de satisfaire et d’effectuer toutes les IRP possibles dans ses routines de distribution n’a besoin d’aucune routine StartIo ni de files d’attente gérées par le pilote pour les IRP.

Les pilotes de niveau supérieur n’ont presque jamais de routines StartIo . La plupart des pilotes intermédiaires n’ont ni routines StartIo ni files d’attente internes ; Un pilote intermédiaire peut généralement passer des IRP avec des paramètres valides à partir de ses routines de répartition et effectuer tout post-traitement requis pour n’importe quel IRP dans sa routine IoCompletion .

Les éléments suivants décrivent, en général, certaines considérations relatives à la conception pour déterminer s’il faut implémenter une routine StartIo avec ou sans files d’attente internes gérées par le pilote pour les IRP.

Routines StartIo dans les pilotes

Pour les périphériques informatiques capables de gérer une seule opération d’E/S d’appareil à la fois, les pilotes de périphérique peuvent implémenter des routines StartIo . Pour ces pilotes, le gestionnaire d’E/S fournit des routines IoStartPacket et IoStartNextPacket pour mettre en file d’attente et supprimer les irps vers et depuis une file d’attente IRP fournie par le système.

Pour plus d’informations sur les routines StartIo , consultez Écriture d’une routine StartIo.

Files d’attente internes pour les IRP dans les pilotes

Si un appareil peut prendre en charge plusieurs opérations d’E/S simultanées, son pilote de périphérique de niveau le plus bas doit configurer des files d’attente de requêtes internes et gérer sa propre mise en file d’attente des IRP. Par exemple, le pilote série système gère des files d’attente distinctes pour les opérations de lecture, d’écriture, de vidage et d’attente sur ses appareils, car il prend en charge les périphériques série full-duplex.

Un pilote de niveau supérieur qui envoie des requêtes à un certain nombre de pilotes de périphériques sous-jacents peut également gérer des files d’attente internes de runtimes d’intégration. Par exemple, les pilotes de système de fichiers ont presque toujours des files d’attente internes pour les irps.

Pour plus d’informations, consultez Files d’attente IRP gérées par le pilote.

Synchronisation de file d’attente interne

Les pilotes avec des threads dédiés aux appareils et des pilotes de niveau supérieur qui utilisent des threads de travail exécutifs (y compris la plupart des pilotes de système de fichiers) configurent généralement leur propre file d’attente pour les irps. La file d’attente est partagée par le thread de pilote ou le rappel worker-thread fourni par le pilote et par d’autres routines de pilote qui traitent les irps.

Un pilote qui implémente sa propre structure de file d’attente doit s’assurer que l’accès à la file d’attente est synchronisé et que les irps annulés sont supprimés de la file d’attente. Pour simplifier cette tâche pour les enregistreurs de pilotes, les files d’attente IRP cancel-safe fournissent une infrastructure standard que vous pouvez utiliser lors de l’implémentation d’une file d’attente IRP. Pour plus d’informations, consultez Annuler les files d’attente IRP sécurisées . Il s’agit de la méthode recommandée pour implémenter une file d’attente IRP.

Les pilotes peuvent également implémenter la synchronisation de toutes les files d’attente IRP et annuler la logique explicitement. Par exemple, un pilote peut utiliser une file d’attente verrouillée. Les routines de répartition du pilote insèrent des irps dans la file d’attente verrouillée et un thread créé par le pilote ou le rappel de thread de travail du pilote les supprime en appelant les routines de prise en charge exInterlockedXxxList .

Par exemple, le pilote du contrôleur de disquette système utilise une file d’attente verrouillée. Son thread dédié à l’appareil gère le même traitement des IRP que celui effectué par les routines StartIo d’autres pilotes de périphérique et une partie du même traitement des IRP que celui effectué par les routines DpcForIsr d’autres pilotes de périphérique.

Files d’attente internes avec des routines StartIo dans les pilotes

Un pilote qui gère ses propres files d’attente internes peut également avoir une routine StartIo , mais ce n’est pas nécessaire. La plupart des pilotes d’appareil de niveau inférieur ont une routine StartIo ou gèrent leur propre file d’attente des IRP, mais pas les deux.

Une exception à cela est le pilote de port SCSI, qui a une routine StartIo et gère les files d’attente internes des IRP. Le gestionnaire d’E/S met en file d’attente les IRP vers la routine StartIo du pilote de port dans la file d’attente de périphériques associée à l’objet de périphérique créé par le pilote qui représente un adaptateur HBA SCSI. Le pilote de port SCSI configure et gère également les files d’attente de périphériques pour les irps sur chaque appareil cible (correspondant à une unité logique SCSI) sur n’importe quel bus SCSI piloté par HBA sur l’ordinateur.

Le pilote de port SCSI utilise ses files d’attente de périphériques supplémentaires pour contenir les IRP envoyés à partir des pilotes de classe SCSI dans des files d’attente spécifiques à l’unité logique chaque fois qu’un appareil d’un bus SCSI est particulièrement occupé. En effet, les files d’attente de périphériques supplémentaires spécifiques à l’unité logique de ce pilote permettent au pilote de port SCSI de sérialiser les opérations pour les périphériques SCSI hétérogènes via un HBA tout en maintenant chaque appareil sur les bus SCSI de ce HBA aussi occupé que possible.