[Kos-cvs] [kos] Modification CVS par thomas
KOS CVS
Gestion CVS KOS <d2@kos.enix.org>
Sun, 24 Mar 2002 18:28:04 +0100 (CET)
Module : kos
Modifié par : thomas 24/03/02 18:28:04
Fichiers modifiés :
modules/kmem : _kslab_cache_alloc.c
modules/kos : wolfgang.c
modules/libhash: _libhash.c
modules/x86/mm : _mm.h _rmap.c _vmap.c mm.c
Détails :
Mise en place de arch_remap_virtual_page
Qques details :
- on est bien oblige de mapper quelque part la page physique
cible. On le fait toujours en CORE_KERNEL_VIRTUAL_ADDR -
_get_gpfm_ram_size() - PAGE_SIZE. On a donc un lock pour proteger
l'utilisation de cette zone : arch_remap_tmp_page.
- on n'ajoute jamais de rmap pour cette page, ca sert a rien, elle
est mappee que tres tres tres temporairement par
arch_remap_virtual_page.
- le deplacement du rmap n'est pas optimise : j'ai deux sessions : la
premiere pour virer le rmap du gpfme source, et la deuxieme pour
ajouter le rmap au gpfme cible. On pourrait optimiser en deplacant
directement le rmap d'une liste a l'autre, mais c'est relativement
chiant, faut encore se mefier des locks, et les listes simplement
chainee c'est galere.
Pour l'instant au niveau des tests, c'est dans wolfgang.c, je deplace
la page de code que je suis en train d'executer (je m'auto
deplace). Ca marche nickel.
Theoriquement ma fonction est capable de deplacer une page n'importe
ou (espace user de n'importe quelle team), mais pas teste.
Pas teste non plus le deplacement de la pile courante.
Note : faudrait revoir get_gpfme_at_phys_addr, c'est tres tres chiant
le coup du *flags, et du gpfme_unlock qu'il faut faire apres :((