IRQ, PIC et Interruptions

Avant de continuer sur le kernel, on est bien obligé de parler de matériel puisqu'un des rôles d'un kernel est de causer avec le matos.

Pour cet article, on parlera des interruptions.

Une interruptions porte bien bien son nom, pour les interruptions matérielles c'est une façon pour les périphérique de se signaler au CPU (et donc indirectement au kernel) pour lui dire qu'il s'est passé quelque chose.

Ça ressemble à quelque chose du genre :

• clavier : Ho merde merde merde putain ! CPU ! Arrête tout !
• CPU (qui arrête ce qu'il faisait) : huh ? quoi ? y'a le feu ?
• clavier : Quelqu'un a appuyé sur une de mes touches !!!!!!!!!!!!!!!!!
• CPU : Wow ! Dingue ... C'est bon j'ai prévenu le kernel, retourne dormir.
• clavier : kthxbye!

Bon, c'est pas tout a fait exactement comme ca, mais pas loin. ;)

Il y a 3 grands type d'interruptions :

• Les exceptions : qui permet au CPU de se signaler au kernel (ex : division par zero)
• Les interruptions materielles (IRQ) : qui permet au matériel de se signaler au CPU (ex: clavier)
• Les interruptions logicielles : qui permet au logiciel de se signaler au kernel (ex : un appel système)

Les interruptions logicielles, c'est pas pour maintenant. J'ai présenté au dernier article la méthode principale du kernel (start), mais pour l'instant il n'a encore rien fait. (et je ne présente pas les interruptions maintenant pour rien, puisque cela va être une des premières chose dont il va devoir s'occuper pour démarrer)

Manière que le matériel ne soit pas connecté directement au CPU, parce que ca serait vraiment moche, il existe un controlleur qui s'appelle le PIC (Programmable Interrupt Controller). Sur nos PC modernes c'est l'APIC (pour Advanced) mais il est capable de fonctionner comme un PIC et Cosmos ne gère par encore l'APIC, et puis c'est plus compliqué à comprendre.

Le role du PIC est de gérer les interruptions matérielle pour le CPU.

Le clavier envoi une impulsion électrique au PIC, le pic transforme ça en quelque chose que le CPU comprend, interromps le CPU, envoie le message au CPU qui fera passer ca au kernel qui fera ce qu'il veut avec, le kernel dit au cpu qu'il a fini qui dit au PIC qu'il a fini. Pendant ce temps il ne peut rien se passer d'autre, il faut donc que cela aille très vite.

Sur les plus anciennes architectures IBM PC et PC/XT il y a un seul PIC (le 8259).

Sur les PC/AT il y en a 2 qui sont chaînés.

Chaque PIC 8259 a 8 entrées qui peuvent être connectés à 8 périphériques.

Avec 2 PIC ca fait 15 périphériques et non 16 car une entrée sert au chaînage des 2 PICs. Le premier PIC est appelé "maître" et le 2ème "esclave".

Chaque entrée est numérotée et on dit généralement : IRQ0 pour la première entrée, IRQ1 pour la 2ème, etc jusqu’à IRQ15. Ceux qui ont fait du DOS doivent se souvenir :)

Le standard ISA (wow, ca date) definit les réservations IRQ suivantes :

• IRQ 0 : Programmable Interval Timer (le PIT, un oscillateur avec des diviseurs et autres joyeuseté)
• IRQ 1 : Clavier
• IRQ 2 : Cascade (pour le chainage des 2 PIC)
• IRQ 3 : COM 2 (port série 2)
• IRQ 4 : COM 1 (port série 1)
• IRQ 5 : LTP 2 (port parallèle 2)
• IRQ 6 : Lecteur de disquette
• IRQ 7 : LPT 1 (port parallèle 1)
• IRQ 8 : Horloge CMOS
• IRQ 9, 10, 11 : libre
• IRQ 12 : Souris
• IRQ 13 : FPU/Coprocesseur/Inter-processeur
• IRQ 14 : ATA 1 (Disque dur 1)
• IRQ 15 : ATA 2 (Disque dur 2)

Les IRQ 0 à 7 sont gerées par le 1er PIC, les IRQ 8 à 15 par le 2ème.

Quand le 2ème pic recoit une interruption il appelle l'IRQ 2 (du premier PIC pour qu'on s'occupe de lui. Car le 2ème PIC ne peut pas interrompre le CPU directement il faut que le 1er le fasse a sa place)

Sans aller jusqu'à une démonstration d'assembleur x86, il faut quand même en parler un tout petit peu. Les cpu intel ont une instruction OUT et des "ports". Sans rentrer dans les details :

• pour causer au PIC master il faut utiliser les ports 20h et 21h,
• Et pour le PIC slave c'est A0 et A1h.

Quand le CPU est interrompu par une interruption(!) materielle, il doit savoir quoi en faire. Pour cela il y a l'interrupt vector table (je sais pas comment traduire ça en français). Cette table peut contenir l'instruction a exécuter, mais en général elle contient plutôt l'instruction "JMP adresse" qui dit au cpu que la fonction a exécuter est ailleurs (comprendre : une fonction du kernel).

La joyeuseté est qu'il y a eu un gros foirage (merci IBM) et que la table pour les interruption matérielle et la table pour les exceptions CPU se marchent dessus. Heureusement on peut redéfinir l'endroit ou se trouve la table pour gérer les interruptions matérielle. C'est une des premières chose que fera le Kernel COSMOS. Il s'occupera par la même occasion des "masques" d'interruptions qui sert a dire au PIC d'ignorer certaines interruptions matérielles. (par ex : ignorer les IRQ 7)

Pour resumer :

1. Un peripherique envoi une impulsion au PIC
2. Le PIC recoit une impulsion sur une de ses lignes
3. Le PIC set un bit en interne pour se souvenir qu'une interruption est demandée
4. Le PIC vérifie si l'interruption n'est pas masquée
5. Le PIC vérifie si cette interruption n'est pas déjà en cours de traitement par le CPU.
6. si 4 et 5 sont ok, le PIC interromps le CPU
7. Quand le CPU est interrompu, il interroge les 2 PICs (via les ports dont on a parlé plus haut) pour savoir lequel est responsable (les 2 sont chainés et seul le master peu interrompre le CPU)
8. Le PIC responsable repond en indiquant l'adresse de l'interrupt vector table qui contient l'instruction a executer par le CPU (donc en general, un JMP)
9. En regle general la fonction qui est appelé par le CPU (on est dans le kernel là) interroge le peripherique qui a demandé une interruption (par exemple si c'est l'IRQ 1, il demande au clavier quelle touche est pressée)
10. Quand le kernel a fini de gerer l'interruption il previent le PIC que la gestion de cette instruction est terminée.
11. Tout le monde reprend une activité normale jusqu'a la prochaine exception

Pour les exceptions : C'est le CPU qui s'interromps lui même, il regarde dans la table (fournie par le kernel) ce qu'il doit executer quand, par exemple, on tente de lui faire faire une division par zero.

Pour le prochain article, j'approfondirai ça, où bien j'indiquerai comment le kernel Cosmos gere ce joyeux bazar.