Selon ce que j'ai lu jusqu'à présent, "lorsque le noyau reçoit une interruption, tous les gestionnaires enregistrés sont invoqués".
Je comprends que les gestionnaires enregistrés pour chaque IRQ peuvent être consultés via /proc/interrupts
, et je comprends également que les gestionnaires enregistrés proviennent des pilotes qui ont appelé à request_irq
passer un rappel à peu près de la forme:
irqreturn_t (*handler)(int, void *)
D'après ce que je sais, chacun de ces rappels de gestionnaire d'interruption associé à l'IRQ particulier devrait être invoqué, et c'est au gestionnaire de déterminer si l'interruption doit en effet être gérée par lui. Si le gestionnaire ne doit pas gérer l'interruption particulière, il doit renvoyer la macro du noyau IRQ_NONE
.
Ce que j'ai du mal à comprendre, c'est comment chaque pilote est censé déterminer s'il doit gérer l'interruption ou non. Je suppose qu'ils peuvent suivre en interne s'ils sont censés s'attendre à une interruption. Si c'est le cas, je ne sais pas comment ils pourraient faire face à la situation dans laquelle plusieurs pilotes derrière le même IRQ attendent une interruption.
La raison pour laquelle j'essaie de comprendre ces détails est parce que je joue avec le kexec
mécanisme pour ré-exécuter le noyau au milieu du fonctionnement du système tout en jouant avec les broches de réinitialisation et divers registres sur un pont PCIe ainsi qu'un PCI en aval dispositif. Et ce faisant, après un redémarrage, je reçois soit des paniques du noyau, soit d'autres pilotes se plaignant de recevoir des interruptions même si aucune opération n'a eu lieu.
La façon dont le gestionnaire a décidé que l'interruption devait être gérée est le mystère.
Edit: Dans le cas où c'est pertinent, l'architecture CPU en question l'est x86
.