[Kos-misc] Loader / Capabilities via les symboles / ISR a plusieurs niveaux
d2
kos-misc@enix.org
18 Sep 2000 10:27:36 +0200
Bonjour tout le monde,
Bon, pas eu de nouvelles ni de Thomas, ni de Julien. Faites-nous signe
des que vous reviendrez a la vie. Pour la version primaire du linker
qui ne linke pas encore tout a fait, va donc falloir attendre encore
un peu.
Concernant ton test sur les symboles du type pentium_is_present : le
faire des le chargement d'un module, ca me gene. Je sais, ca evite de
decharger un module si le processeur n'est pas correct. Mais ca me
gene. Ca me paraitrait plus propre que ce soit un bout de code d'init
du module qui renvoit ERR_MATCH_ARCH pour provoquer son dechargement
immediat. Le test reposerait alors sur des appels a des fonctions du
noyau, ou des lectures de structures de donnees internes au noyau
definissant la machine. En plus, ca permettrait de faire des tests
plus compliques comme : verifier si le stepping du proc est superieur
a 2, quand le proc est un PIII Coppermine... Evidemment, ca necessite
d'implanter le code de dechargement des modules.
Sinon, concernant le traitement des interruptions a plusieurs niveaux,
dont parle Christophe (l'histoire des callbacks), je n'ai pas grand
chose a detailler. Il s'agit principalement de faire en sorte que le
noyau soit le moins longtemps possible verrouille pendant un
traitement d'interruption.
Quand une interruption est levee, si on se contente de faire le sti
uniquement a la fin du traitement de celle-ci, tout marchera nickel,
sauf qu'on passera beaucoup de temps a pas pouvoir accepter d'autres
irqs, alors qu'on fait des traitements qui ne sont pas vraiment
critiques, et qui ont une portee purement interne au driver.
Exemple type : irq clavier. On reste en exclusivite totale jusqu'a ce
que la touche tapee soit decodee et mise dans le buffer systeme
clavier. Pendant ce temps, si un irq ide ou temps est arrivee, on n'a
pas pu la traiter. Donc on a perdu en reactivite (temps de
reponse). L'idee est donc de scinder l'isr en (au moins) 2 parties :
traitement en exclusivite totale / traitement en concurrence avec les
autres irqs (masquage de l'irq en cours de traitement). Dans le cas du
clavier, ca donne :
- En exclu totale (cli) : recuperer les scancodes tapes
- Hors exclu totale (mais avec masquage niveau de l'irq clavier) :
decoder les scancodes, ranger dans le tampon systeme clavier,
eventuellement debloquer la/les taches en attente
Avec Hlide, on avait pense diviser le traitement des IRQs en 3 parties :
- Exclu totale
- Masquage jusqu'au niveau de l'irq traitee
- Aucun masquage : recours a des verrous pour la synchro sur les
donnees critiques
Tout ca necessite bien sur de gerer l'emboitement des isr.
--
d2