Fonctionnement des pilotes (PCIe et USB, par exemple)

Question

Je suis curieux de savoir comment fonctionnent les pilotes en général. Je comprends les concepts de base et aussi comment fonctionne un seul conducteur. Où je suis confus est comment ils fonctionnent quand plusieurs conducteurs sont impliqués.

Laissez-moi vous expliquer ma question par un exemple:

Supposons que j'ai un PCIe et une interface USB dans HW. L'interface principale de l'hôte (où réside le pilote, le système d'exploitation et les applications) est PCIe. L'interface USB est accessible à l'hôte via PCIe. Donc, dans ce cas, je aurais un pilote pour PCIe ainsi que pour USB. Lorsque les données doivent être transférées via USB par application, l'application appelle les appels système/OS. Cela finirait par atterrir dans le pilote USB. Est-ce correct?

Une fois le traitement du pilote USB terminé, les appels PCIe doivent être appelés. Qui le fait? est-ce OS ou pilote USB lui-même? Je suppose que ce serait le système d'exploitation, car autrement, cela briserait la philosophie modulaire de base. Mais le fait d'appeler le système d'exploitation semble contre-intuitif car j'ai toujours supposé que le flux allait de l'application au système d'exploitation au pilote et au matériel.

Quelqu'un peut-il jeter un peu de lumière sur ce sujet?

Answer 1

Tout comme dans le code espace utilisateur, il existe des API standardisées pour accéder à différents types de matériel dans le noyau (l'utilisation exacte varie selon le système d'exploitation). En conséquence, il n'est pas vraiment difficile pour un pilote de périphérique d'accéder au pilote d'un autre périphérique via ces API standardisées. (Attention: USB est un protocole très complexe, et de nombreux détails ont été glissés pour garder un message plus court)

La question originale portait sur les cartes PCIe vers USB. Dans cet exemple, je pense qu'il est utile de penser à trois «couches» de pilotes. La première couche est le pilote du contrôleur de bus PCIe, qui contrôle les fonctions spécifiques au bus PCIe, telles que le mappage de MMIO pour les périphériques PCIe et la prise en charge des interruptions de ces périphériques PCIe. La deuxième couche est la couche de contrôleur hôte USB, qui fournit les fonctions pour l'émission de transactions USB normalisées. Enfin, le pilote de périphérique USB (comme un clavier de pilote USB) se trouve sur le dessus de la pile en utilisant la transaction USB standardisée pour implémenter les fonctionnalités du périphérique USB spécifique. Les appels du pilote du clavier appellent les fonctions vers le bas dans le pilote du contrôleur hôte USB, qui peut même appeler le pilote PCIe. Tout cela est fait dans l'espace noyau, même si beaucoup de pilotes distincts sont employés.

La plupart des périphériques PCIe effectuent l'essentiel de leur communication avec la CPU via l'accès MMIO, qui apparaît sous forme de lectures/écritures de mémoire vers le processeur. Généralement, aucune fonction de pilote spécifique n'est nécessaire pour effectuer le transfert de données MMIO de PCIe à CPU (bien qu'il puisse y avoir quelques fonctions d'accès simples pour effectuer une correction endian ou traiter des problèmes de cache).

Les pilotes de contrôleurs hôtes USB sont intéressants en ce qu'ils sont conformes à une norme (telle que XHCI, la norme USB 3.0, que j'utiliserai dans cet exemple) qui dicte une carte mémoire et un comportement standard. Ainsi, il y a généralement un pilote spécifique à la puce qui effectue une initialisation non standard sur le périphérique du contrôleur hôte USB. De plus, ces pilotes spécifiques à la puce récupéreront l'emplacement de la région MMIO normalisée XHCI et fourniront un moyen de recevoir des interruptions du contrôleur XHCI (dans cet exemple, à partir des interruptions PCIe).

Ensuite, cette région de mémoire normalisée et ce mécanisme d'interruption sont transmis à un pilote de contrôleur hôte XHCI générique.Le code XHCI générique ne se soucie pas si le périphérique est PCIe, il se soucie juste qu'il passe une zone de mémoire qui suit la norme XHCI et qu'il reçoit les interruptions correctes Le pilote XHCI fournit les fonctions génériques de transfert USB qui à son tour le clavier USB périphérique peut utiliser pour initier des transactions USB. Pour la plupart, le pilote XHCI va simplement lire/écrire dans la région MMIO qui a été transmise. Cela permet au même code XHCI commun de desservir un large éventail de contrôleurs hôtes USB, dont beaucoup ne sont pas Périphériques PCIe Ainsi, le pilote XHCI peut effectivement faire abstraction du matériel sous-jacent implémentant le contrôleur USB. Ainsi, pour l'exemple posé par la question d'origine, les normes du contrôleur hôte USB sont conçues pour masquer les mécanismes matériels sous-jacents afin de créer un système de pilote USB plus modulaire.