Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Comme indiqué dans la figure Traitement des IRPs dans les pilotes en couches, un système de fichiers est un pilote en deux parties :
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 PSF (processus de système de fichiers)
Un FSD peut créer un ensemble de threads système dédiés au pilote, mais la plupart des FSD utilisent des threads de travail système pour accomplir la tâche 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 des files d'attente de travail internes d'IRPs qu'ils envoient à un ou plusieurs pilotes hiérarchiquement inférieurs, éventuellement pour différents périphériques.
Bien que le pilote de niveau le plus bas indiqué dans les IRPs de traitement dans les pilotes en couches traite chaque IRP en phases via un ensemble de routines discrètes fournies par le pilote, il n’utilise pas les threads système comme le fait le système de fichiers. Un pilote de niveau le plus bas 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 le plus bas ou intermédiaire doivent configurer leurs propres threads système dédiés aux pilotes ou aux périphériques, et ceux qui le font paient une pénalité de performance causée par des commutations de contexte vers leurs threads.
La plupart des pilotes en mode noyau, comme le pilote de périphérique physique dans la figure de Traitement des IRP dans les pilotes en couches, s'exécutent dans un contexte de thread arbitraire : celui de n'importe quel thread 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 les appareils qu’ils servicent dans une partie définie par le pilote de leurs objets d’appareil, appelée extension d’appareil.