[Kos-dev] Travail accompli : resume

[Thomas Petazzoni]

salut,

bon je voulais juste resumer ce que David et moi avions fait pendant ce
WE :

	- fonctions add_virtual_region, resize_virtual_region pour creer et
redimensionner des regions virtuelles.
	- fonction get_region_at_vaddr permet de savoir quelle  region contient
l'adresse virtuelle fournie en argument
	- fonctions d'allocations/desallocations de piles CPL0 pour les threads
noyau et utilisateur
	- fonction create_kernel_thread pour creer un nouveau thread noyau, et
init_kernel_thread_context pour initialiser son contexte avec des
valeurs donnees.
	- fonction map_virtual_to_physical pour mapper une page virtuelle sur
une page physique. attention pour l'instant la synchronisation des PDEs
de la partie noyau est prevue, mais non encore implementee. la fonction
unmap_physical (ou quelque chose d'approchant) permet elle de demapper
tout un range de pages virtuelles.
	- fonction register/unregister_thread qui permettent
d'enregistrer/desenregistrer un thread de la liste globale des threads,
et de la liste des threads de la team mere.
	- correction de bugs dans le loader, au niveau du calcul de BSS et de
.zero. il y avait des ecrasements lors de l'utilisation simultanees de
static, et de globales. c'est notamment la raison pour laquelle le
desassembleur de bochs chiait. il est maintenant fonctionnel (enfin
presque, mais les bugs ne sont plus dus au loader). de toute facon,
david pense changer pour celui de plex86, moins porc et en GPL aussi.
	- creation d'un kernel thread, dont la tache est de terminer
l'initialisation du noyau. il devient ensuite la tache dite 'idle' (qui
tourne quand le proc n'a rien a faire)
	- creation du module lib-x86 destinee a recevoir des fonctions
generiques, mais non portable. ici il y a des fonctions pour gerer des
bitmaps, qui utilisent l'instruction bsf. ces bitmaps sont utilises pour
gerer les piles CPL0. d'ailleurs j'en profite pour signaler (afin qu'on
s'en rappelle, et qu'on se dise pas on est con pourquoi on a mis des
bitmaps c'est lent) qu'on utilise des bitmaps, car nous pensions
utiliser des listes de piles libres, qui en fait seraient des listes de
struct thread libres (etat UNASSIGNED), mais qu'il fallait les trier par
ordre, et trier aussi par ordre croissant d'adresse de pile les threads
utilises, donc que finalement une gestion par bitmap etait plus rapide,
et risquait de presenter moins de bugs.
	- quelques modifications au niveau du module idt, afin qu'un troisieme
argument soit fourni aux handlers d'interruption : le EIP qui a ete
empile, c'est a dire l'adresse de l'instruction qui a provoque l'erreur.
ca sera tres utile pour le debugging :))
	- gestion du page fault, qui alloue une page physique, et la mappe a
l'adresse virtuelle qui convient lorsque la dite adresse virtuelle
appartient a une region. pour l'instant pas de distinction type de
region, pas de check speciaux, rien. c'est le debut. 
	- il y a une team speciale pour le kernel, meme si celui n'a pas
vraiment d'espace d'adressage a lui. cette team englobera tous les
threads noyau (dont le thread d'init, qui deviendra idle), et des
regions virtuelles. pour l'instant ces regions virtuelles sont : une
region qui englobe tout l'identity mapping, afin d'eviter que l'on cree
une autre region virtuelle par dessus cet identity mapping, une region
qui englobe toutes les piles CPL0 des kernel threads, et une region qui
englobe	toutes les piles CPL0 des user threads (ces regions sont
initialisees dans task.c, fonction init_cpl0_stacks_regions).

il me semble que je n'oublie rien. ah si, qu'il faut poursuivre :))

amicalement,

thomas

-- 
PETAZZONI Thomas
thomas.petazzoni@meridon.com     UIN : 34937744
Projet KOS : http://kos.enix.org

 
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif