[Kos-cvs] [kos] Modification CVS par thomas
KOS CVS
Gestion CVS KOS <d2@kos.enix.org>
Thu, 21 Feb 2002 17:06:04 +0100 (CET)
Module : kos
Modifié par : thomas 21/02/02 17:06:04
Fichiers modifiés :
modules/debug : bt.c debug.c debug.h
modules/kos : spinlock.h
modules/task : _task_utils.c
modules/x86/mm : _vmap.c mm.h
modules/x86/task: task.h
Détails :
* Grosse reecriture de arch/mm/_vmap.c (mapping en memoire virtuelle
de pages physiques), avec des spinlocks de partout. Pour l'instant on
a un spinlock pour l'espace kernel (defini dans spinlock.h) et un
spinlock pour l'espace user de chaque team (dans la structure
team_mm_context_t). En gros chaque fonction se decoupe sous la forme
if(IS_KERNEL_PT(vaddr))
{
locker(kernel);
faire le bazar;
delocker(kernel);
}
else
{
locker(l'espace user du dest_mm_context)
faire le bazar;
delocker;
}
Pour le moment les sections couvertes par les spinlocks sont assez
grosses, mais je vois pas sortir comment. J'aurai voulu pouvoir sortir
les add_rmapping et del_rmapping, mais j'ai reflechi et je crois pas
que ce sera possible. (mais pas sur du tout, je suis pas un expert).
Par ailleurs, il faudra faire TRES TRES TRES attention, parce que les
fonctions de _vmap.c appellent add_rmapping, del_rmapping qui font des
locks sur un gpfme donne (pas encore implemente, ce soir peut etre),
et sur {get,put}_physical_page qui font des locks sur les listes de
GPFME, il va donc falloir faire tres tres tres attention a pas avoir
de deadlock !
* Bricolage de debug/ pour que debug/debug n'inclue plus
arch/task/task.h. En gros j'utilise des struct thread au lieu de
thread_t et struct cpu_state au lieu de cpu_state_t. Mais ca fout
moins la merde au niveau des include parce que sinon on avait :
spinlock.h -> assert.h -> debug.h -> arch/task/task.h -> task/task.h
Un peu ennuyeux donc. Maintenant la chaine est rompue et ca marche
nettement mieux !
* Cosmetique dans _task_utils.c
J'attends vos commentaires sur les locks de _vmap.c. Les sections
critiques sont assez larges, je trouve ca moche, mais honnetement je
vois pas comment on peut faire. On pourrait faire des trucs avec un
grain plus fin en ayant un lock pour chaque PT de l'espace noyau, mais
la franchement ca tourne au delire (et c'est pas sur que ca solutionne
le pb).