Open NicolasFloquet opened 12 years ago
En gros c'est juste une fonction qui rajoute un if pour vérifier que l'IRQ n'est pas déjà setté ? (un tableau statique avec une case par IRQ et on passe à 1 quand un IRQ est utilisé et à 0 si le driver relache l'interruption et cette fonction mettrait à jour ce tableau)
Alors ça pour faire simple, ça serait un bon début. Une solution beaucoup plus propre serait que toutes les IRQ soient mappées à un handler du kernel. Quand une interruption survient, c'est ce handler qui s'occupe de dispatcher l'interruption au bon driver. Deux interêts principaux de cette méthode:
Alors certes, ça ajoute un léger overhead en temps d'exécution sur chaque interruptions mais ça fait un truc assez clean au final.
Pourquoi pas. Pour l'overhead, si c'est bien fait, c'est juste une addition, une comparaison et un appel de fonction supplémentaire en gros. C'est pas très grave, je pense.
Ceci me parait assez trivial à faire. Ticket facile à traiter ?
J'aimerais quand même qu'on attende d'avoir traité le problème du scheduler pour se pencher sur celui là. Faut quand même penser que si on ajoute une couche entre l'interruption et le handler d'interruption, on ajoute certes un overhead, mais on décale toute la pile. Donc toutes les handler qui prennent en compte l'état d'exécution empilé à l'interruption devront être adaptés. C'est pas si trivial, et en plus ça va être voué à changer, donc mon avis est d'attendre un peu.
Ok ok, j'attends donc.
Pour configurer le handler appelé lors d'une IRQ, on a la fonction interrupt_set_routine qui fait très bien son boulot. Elle est cependant un peu bas niveau, et rien n’empêche par exemple de faire un driver qui écrase le handler de l'interruption de l'horloge d'ordonnancement (et oui, j'ai testé pour vous :D). Il serait bien à la place de fournir une fonction qui protège un peu ce mécanisme en empêchant d'associer un numero d'IRQ si elle est déjà utilisée. On aurait dont une politique premier arrivé premier servi.