[Kos-cvs] [kos] Modification CVS par d2

[KOS CVS]

Module :	kos
Modifié par :	d2	03/03/02 11:01:08

Fichiers modifiés :
	.              : TODO 

Détails :
Informations supplementaires pour pouvoir avoir 1 lock par liste des
gpfme plutot que 1 seul gros locks. C'est juste une histoire de "break
the tie" de facon arbitraire dans l'ordre d'acquisition/relachement de
2 locks. La solution est de faire ca suivant l'ordre relatif des
adresses virtuelles des locks ou d'une structure qui leur est associee
(ici : l'adresse de la tete de chaque liste, puisque spinlock_t peut
etre vide).

Meme remarque pour le remap : il faut acquerir les locks sur 2 gpfme
differents => utiliser les adresses relatives des structures gpfme (ou
des pages physiques associees, mais c'est pas vraiment la peine).

Un mode d'emploi pour l'histoire des locks gpfm, que j'ai oublie de
donner :

- en dehors de _pmm.c, pas besoin de jamais se soucier des locks des
listes de gpfm. Toutes les fonctions exportees sont 'safe' vis a
vis de ces locks (CE lock pour l'instant). De toutes facons, ces
locks (CE lock pour l'instant) ne sont pas accessibles en dehors
de pmm (pas exporte).
- en dehors de _pmm.c (encore), les fonctions qui
renvoient/utilisent des gpfme_t le prennent en parametre/le
renvoient en NON LOCKE (ie gpfme->lock NON pris). En interne, ces
fonctions le lockent. Le lock gpfme->lock ne doit donc JAMAIS etre
pris qd on appelle l'une quelconque des fonctions exportees de
pmm.
- en dehors de _pmm.c (toujours), des qu'on veut lire/modifier un
gpfme, il faut le locker (gpfme->lock) en read ou write. On est
assure que pdt ce temps la, _pmm.c ne pourra pas y toucher en
aucune facon (en particulier pas le changer de liste).

- dans _pmm.c : il EST garanti que avant de modifier/lire un gpfme, on
prend le lock dessus (gpfme->lock) d'abord, avant de toucher aux
listes de gpfm.