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

[KOS CVS]

Module :	kos
Modifié par :	d2	02/03/02 15:06:10

Fichiers modifiés :
	.              : TODO 
	modules/kmem   : _kvmem_init.c _kvmem_utils.c 
	modules/kos    : _vr_test.c system.h wolfgang.c 
	modules/pmm    : _pmm.c pmm.c pmm.h 
	modules/task   : _task_kstack.c 
	modules/x86/mm : _team_mm_context.c _vmap.c mm.h 
	modules/x86/task: _thread_cpu_context.c 

Détails :
- pmm.c : Revu la structure du gpfme et les listes de gpfme :
#define PHYS_PAGE_FREE       0
#define PHYS_PAGE_KERNEL     1
#define PHYS_PAGE_USER       2
#define PHYS_PAGE_HW_MAPPING 3
k_ui32_t page_type :2;

/* For PHYS_PAGE_{KERNEL,USER} pages */
#define PHYS_PAGE_NON_SWAPPABLE 0
#define PHYS_PAGE_SWAPPABLE     1
k_ui32_t swap_status :1;

+ plus de kernel_locked : remplace par la combinaison
PHYS_PAGE_KERNEL et PHYS_PAGE_NON_SWAPPABLE
=> plus logique parce que la page n'est pas "inbougeable".
+ tout passe par get_gpfme_at_paddr, qui peut aussi chercher le
gpfme dans la liste des hw_mapping (ie en dehors de la mem
physique) si on ne la trouve pas en memoire physique.
+ fonction change_gpfme_swap_status
+ 4 listes : free, swappable (avec kernel, user), non swappable
(idem), hw_mapping
=> get_physical_page prend 2 arguments
(=> nouvelle taille=28 [ancienne=36])

_vmap.c: renommage index_team/must_map_foreign en
pd_index_in_pd_table/is_foreign_mm_context

J'ai longtemps hesite a rajouter un flag (1 bit en union avec le
swap_status) dans le gpfme, speciale dedicace pour les hw_mapping. En
effet, on peut imaginer que certains periph ont leur mapping qui
recouvre la RAM (p.ex : 4G de RAM, cartes video vers 2G). Dans ce cas,
que faire qd on veut demapper un tel periph : est-ce qu'on rebalance
les gpfme du periph dans la liste "free", ou est-ce qu'on perd le
gpfme definitivement ? Ou est-ce qu'on interdit le hw_mapping d'etre
libere (tout simplement) ? Je risque de le rajouter, ce flag.

Tout de suite la suite (API pour hw_mapping d'abord, arch_remap
ensuite).