Contexte du thread de pilote
Comme indiqué dans l’illustration Traitement des IRP dans les pilotes en couches , un système de fichiers est un pilote en deux parties :
Un pilote de système de fichiers (FSD), qui s’exécute dans le contexte d’un thread en mode utilisateur qui appelle un service système d’E/S
Le gestionnaire d’E/S envoie l’IRP correspondant au FSD. Si le FSD configure une routine d’achèvement pour un IRP, sa routine d’achèvement n’est pas nécessairement appelée dans le contexte du thread en mode utilisateur d’origine.
Un ensemble de threads de système de fichiers, et éventuellement un processus de système de fichiers (FSP)
Un FSD peut créer un ensemble de threads système dédiés aux pilotes, mais la plupart des FSD utilisent des threads de travail système pour effectuer le travail sans lier les threads en mode utilisateur qui effectuent des demandes d’E/S. Tout FSD peut configurer son propre espace d’adressage de processus dans lequel ses threads dédiés au pilote s’exécutent, mais les FSD fournis par le système évitent cette pratique pour conserver la mémoire système.
Les systèmes de fichiers utilisent généralement des threads de travail système pour configurer et gérer les files d’attente de travail internes des IRP qu’ils envoient à un ou plusieurs pilotes de niveau inférieur, éventuellement pour différents appareils.
Bien que le pilote de niveau le plus bas indiqué dans la figure Traitement des IRP dans les pilotes en couche traite chaque IRP par étapes par le biais d’un ensemble de routines discrètes fournies par le pilote, il n’utilise pas de threads système comme le fait le système de fichiers. Un pilote de niveau inférieur n’a pas besoin de son propre contexte de thread, sauf si la configuration de son appareil pour les E/S est un processus si long qu’il a un effet notable sur les performances du système. Peu de pilotes de niveau inférieur ou intermédiaire doivent configurer leurs propres threads système dédiés aux pilotes ou aux appareils, et ceux qui paient une pénalité de performances causée par les changements de contexte vers leurs threads.
La plupart des pilotes en mode noyau, comme le pilote de périphérique physique dans la figure Traitement des irps dans les pilotes en couches , s’exécutent dans un contexte de thread arbitraire : celui de tout thread qui se trouve être actuel lorsqu’ils sont appelés pour traiter un IRP. Par conséquent, les pilotes conservent généralement l’état de leurs opérations d’E/S et des appareils qu’ils gèrent dans une partie définie par le pilote de leurs objets de périphérique, appelée extension de périphérique.