Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fonction de configuration des IRQ #148

Open
NicolasFloquet opened this issue Jun 25, 2012 · 6 comments
Open

Fonction de configuration des IRQ #148

NicolasFloquet opened this issue Jun 25, 2012 · 6 comments

Comments

@NicolasFloquet
Copy link
Member

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.

@MaximeCheramy
Copy link
Member

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)

@NicolasFloquet
Copy link
Member Author

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:

  • On ne touche à la table des interruptions qu'une fois (au boot) et après on y touche plus.
  • On peut envisager de demander au kernel de faire des stats sur les interruptions (genres les compter, cf /proc/interrupts)

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.

@MaximeCheramy
Copy link
Member

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.

@MaximeCheramy
Copy link
Member

Ceci me parait assez trivial à faire. Ticket facile à traiter ?

@NicolasFloquet
Copy link
Member Author

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.

@MaximeCheramy
Copy link
Member

Ok ok, j'attends donc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants