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

[KOS CVS]

Module :	kos
Modifié par :	d2	02/03/02 18:21:21

Fichiers modifiés :
	modules/kmem   : _kslab_cache_free.c _kslab_cache_grow.c 
	modules/pmm    : _pmm.c pmm.c pmm.h 
	modules/x86/mm : _vmap.c 

Détails :
-- pmm:
Commentaires javadoc dans le .h

Nouveau flag hw_mapping_reclaiming_status. Qd il est a 1, ca veut
dire que quand on demappe le preriph qui etait sur ce gpfme, le
gpfme est mis dans la liste des free (=> dispo pour les
get_physical_page()). Ce flag est automatiquement positionne qd on
utilise declare_hw_mapping() : si l'adresse physique correspond a
une zone precedemment allouable (et free), alors le hw_mapping est
reclaimable. Pour enlever un hw_mapping, il suffit d'utiliser le
put_physocal_page qui se charge de faire le reclaim si possible, ou
de 'dropper' le gpfme sinon.

fonction add/remove_additional_allocatable_page() pour ajouter des
regions allouables en plus de la RAM. Idem : si on mappe un
hw_mapping la-dessus, le hw_mapping est marque reclaimable.

les fonctions
get_gpfme_at_virt_addr/get_gpfme_at_phys_addr/change_gpfme_swap_status
sont suffixees avec _unsafe pour que ce soit explicite. Probleme :
dans arch/mm/vmap : le lock n'est pas pris.

NOTE: les fonctions de hw_mapping et de additional_allocatable_page
ne sont pas du genre rapide (marchent par page a mapper/ajouter,
avec le lock global a chaque fois). Mais j'estime que c'est pas
genant, vu qu'elles seront appelees que 2 ou 3 fois durant la vie de
tout le systeme.

-- Autres fichiers: MAJ avec les suffixes _unsafe.

Etape imminente : 1 lock par gpfme + 1 lock par liste des gpfme (et 1
semaphore prevu sur la liste free).