Une analyse approfondie des interruptions du pilote de périphérique Linux (1) (3)

6. Non-réentrance des gestionnaires d'interruptions

Dans la section précédente nous avons mentionné qu'il est parfois nécessaire de masquer les interruptions, mais pourquoi devrions-nous masquer cette interruption ? Cela n'est pas dû au fait qu'il est techniquement impossible de paralléliser la même routine d'interruption, mais à des considérations de gestion. La raison pour laquelle les nouvelles interruptions de la même IRQ doivent être bloquées pendant le traitement des interruptions est que le gestionnaire d'interruption n'est pas réentrant, donc le même gestionnaire d'interruption ne peut pas être exécuté en parallèle. Nous donnons ici un exemple. À partir de cet exemple, nous pouvons voir que si un gestionnaire d'interruption peut être parallélisé, alors le verrouillage du pilote est susceptible de se produire. Lorsque le pilote est verrouillé, votre système d'exploitation ne plante pas nécessairement, mais le périphérique pris en charge par le pilote verrouillé ne peut plus être utilisé - lorsque le pilote de périphérique meurt, le périphérique meurt également.

L'événement qui déclenche PS1 amènera A1 à générer une interruption, puis B1 lira les données existantes dans R1, puis le code C1 écrira les données dans R2. L'événement qui déclenche PS2 amènera A2 à générer une interruption, puis B2 supprimera les données dans R1, puis C2 lira les données dans R2.

Si PS1 est généré en premier, et lorsqu'il est exécuté entre A1 et B1, si PS2 est généré, A2 générera une interruption et interrompra PS2 (accrocher à la fin de la file d'attente des tâches). R1 ont été supprimés. Lorsque PS2 s'exécute sur C2, puisque C1 n'a pas encore écrit de données sur R2, C2 sera suspendu ici et PS2 dort sur le code C2 jusqu'à ce qu'il soit réveillé par un signal lorsque les données sont lisibles. En effet, les données de R1 que B2 dans PS1 voulait initialement lire ont été supprimées par B2 dans PS2, donc la page PS1 restera en veille sur B1 jusqu'à ce qu'elle soit réveillée par un signal lorsqu'il y a des données à lire. De cette façon, l'événement qui réveille PS1 et PS2 n'arrivera jamais, donc PS1 et PS2 sont verrouillées.

Étant donné que le pilote de périphérique doit gérer les registres de périphérique, il est difficile d'écrire du code réentrant, car les registres de périphérique sont des variables globales. Par conséquent, le moyen le plus simple consiste à interdire le parallélisme des gestionnaires d’interruptions du même périphérique, c’est-à-dire que le gestionnaire d’interruptions du périphérique n’est pas réentrant.

Une chose doit être claire : dans le noyau Linux après la version 2.0, toutes les moitiés supérieures sont ininterrompues (les opérations de la moitié supérieure sont atomiques) ; les moitiés inférieures des différentes sections de périphériques peuvent s'interrompre, mais une moitié inférieure spécifique ne peut pas être interrompue par elle-même (c'est-à-dire que la même moitié inférieure ne peut pas être mise en parallèle).

Étant donné que le gestionnaire d'interruption doit être non réentrant, les programmeurs n'ont pas à se soucier de l'écriture de code réentrant. D'après mon expérience, l'écriture de pilotes de périphériques réentrants est possible, mais l'écriture de gestionnaires d'interruptions réentrants est très rare et presque impossible.

7. Évitez l'apparition de conditions de concurrence

Nous savons tous qu'une fois qu'une condition de concurrence se produit, une impasse peut se produire et, dans les cas graves, l'ensemble du système peut être verrouillé. Assurez-vous donc d’éviter les conditions de course. Je ne dirai pas grand-chose ici, mais tout le monde doit juste prêter attention à une chose : la plupart des conditions de concurrence provoquées par les interruptions sont causées par le processus du noyau, les interruptions étant mises en veille. Par conséquent, lors de l'implémentation d'interruptions, vous devez faire attention à laisser le processus dormir. Si nécessaire, vous pouvez utiliser cli, sti ou save_flag, restaurer_flag. Veuillez vous référer à l'ouvrage de référence spécifié dans cet article pour des détails spécifiques.

8. Implémentation

Comment implémenter la routine d'interruption du pilote dépend des lecteurs. Tant que vous lisez attentivement le code source de la routine courte et comprenez les règles d'écriture des routines d'interruption du pilote, vous pouvez écrire votre propre routine d'interruption. Tant que les concepts sont corrects et que votre code est écrit selon les bonnes règles, cela a du sens. J'insiste toujours sur le fait que les concepts viennent en premier et que la quantité de code pouvant être écrite est secondaire. Nous devons avoir des concepts corrects pour penser correctement.

(T114)

Ce qui précède est une analyse approfondie des interruptions du pilote de périphérique Linux (1) (3). Pour plus de contenu connexe, veuillez prêter attention au site Web PHP chinois (www). .php.cn) !