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

KOS CVS Gestion CVS KOS <d2@kos.enix.org>
Sun, 24 Mar 2002 15:14:51 +0100 (CET)


Module :	kos
Modifié par :	thomas	24/03/02 15:14:51

Fichiers modifiés :
	.              : MkVars TODO 
	modules/kmem   : _kvmem.h _kvmem_init.c kmem.c kmem.h 
	modules/pmm    : _pmm_init.c 
	modules/x86/mm : _rmap.c mm.c 

Détails :
Travail sur la creation des rmap existants
------------------------------------------

- changement de l'ordre d'initialisation des modules du niveau 1 :
d'abord pmm, puis kmem, puis arch-mm (avant c'etait pmm, arch-mm,
kmem). Ceci ne pose aucun probleme, et permet d'avoir kslab
initialise avant d'arriver sur arch-mm.
- les rmap des pages physiques existantes sont maintenant crees en
level 1 de arch-mm (et non plus en post init tres loin, quand plein
de bazar est alloue).
- Au lieu de parcourir les 1024 entrees du PD, on sait qu'on a rien
alloue dans l'espace user => on se limite aux 512 premieres entrees
(et encore on pourrait affiner).
- Au lieu de parcourir tous les PTs comme un gros violent, on
parcourt la liste des used_page_range,  cree auparavant par kvmem
(dans kmem). C'est la liste des ranges virtuels inutilisables. Et
pour chacun de ces ranges, on ajoute les rmap qu'il faut pour
toutes les pages, et hop le tour est joue. C'est achement plus
rapide qu'avant, et ca donne les memes resultats (j'ai compare les
rmap ajoutes un par un, oui oui).
- J'ai trouve a quoi corresponde les quelques pages qui servent a
rien (pas mappes) et qui sont supprimes a la fin de
l'initialisation des rmap. C'est les PT alloues au niveau du loader
et qui servaient a l'identity mapping => on n'en a plus besoin,
donc c'est parfait. De toute facon on devait trouver un moyen ou un
autre des les virer.
- Correction bug tres mineur dans _pmm_init.c : on avait (fonction init_gpfm)

for (i = 1 ; i < 3 ; i++)
{
if (sieve_gpfm[i].flags.page_type != PHYS_PAGE_FREE)
{
INIT_GPFME(gpfm.ram_map + i);
gpfm.ram_map[i].address = i << PAGE_SIZE_SHIFT;
gpfm.ram_map[i].flags.page_type   = PHYS_PAGE_KERNEL;
gpfm.ram_map[i].flags.swap_status = PHYS_PAGE_NON_SWAPPABLE;
GPFM_LIST_ADD(non_swappable, gpfm.ram_map + 1);
}
else
init_ram_gpfme(kp, i);
}

=> Remplacement du GPFM_LIST_ADD(non_swappable, gpfm.ram_map + 1);
par GPFM_LIST_ADD(non_swappable, gpfm.ram_map + i);

Un seul truc pas tres propre : pour pouvoir parcourir la liste des
used ranges maintenue par kvmem, on a besoin de :
1. du proto de chained_page_range (_kvmem.h)
2. du debut de la liste
=> Obligation de creer une fonction exportee pour avoir la tete de la
liste, et on inclut _kvmem.h dans arch/mm/_rmap.h. Oui je sais c'est
gore, mais AMHA moins gore que de mettre le proto de struct
chained_page_range dans kmem.h, nan ?
J'ai essaye de retrouver les memes ranges a partir de rmap (sans
utiliser la liste des ranges de kvmem), mais en fait ca marche pas,
parce que on connait les ranges de _kvmem_init, mais par contre on
connait pas les ranges que kvmem a cree en plus. => obligation
d'utiliser la liste des ranges de kvmem.

Voila, ouf, c'etait un peu long, mais je suis arrive au bout ;)