[Kos-dev] Projet UTBM

Thomas Petazzoni kos-dev@enix.org
Mon, 06 May 2002 10:12:31 +0200


Bonjour,

J'en ai deja parle a d2 et Julien. Je vais realiser dans le cadre d'une
UV a l'UTBM une partie de KOS.

Sujet du projet : programmation des primitives fork() et exit() dans le
noyau KOS.

Le projet consiste en la realisation des primitives de creation de
processus fork() et de destruction de processus exit(). Il conviendra
donc de realiser a la fois les parties au niveau utilisateur (libc) et
au niveau noyau.

Afin de mener a bien cette realisation, KOS dispose deja des elements
suivants :
 - creation de team, de threads et ordonnancement.
 - gestion de la memoire virtuelle et physique
 - gestion du page fault
 - mini chargeur ELF permettant de connaitre le point d'entree d'un
programme
 - driver pour disques IDEm et driver de systeme de fichier FAT (pour la
lecture du programme a executer)
 - une petite libc permettant aux applications utilisateur de realiser
divers appels systemes.

Toutefois, la realisation des deux primitives fork() et exit() necessite
quelques ameliorations :
 - gestion des file descriptors (resources) dans un tableau
 - ??? peut etre d'autre, mais je ne vois pas

Restrictions :
 - pas de gestion du COW (recopie totale des PD et PT)
 - pas de gestion du MAP_SHARED
 - j'ai prevu un fork() qui recopie tous les threads, pas seulement le
thread courant (est-ce que ca doit marcher comme ca ?)

Algo du fork() :
 * creation d'une nouvelle team
 * la mother_team de la nouvelle team est la team courante
 * recopie de tous les threads
 * recopie de l'address spacem des virtual regions et access ranges
 * recopie des PDs, PTs (sans oublier de mettre a jour les rmaps)
 * modifier l'adresse de l'eauivalent au thread courant dans la nouvelle
team pour qu'a son execution, il saute sur un code faisant juste return
); et retourne dans le thread en lui meme
 
Algo du exit() :
 * marquer tous les threads comme etant non eligibles
 * detruire tous les threads
 * liberer tous les PD/PT/pages utilises
 * detruire les structures virtual_region, address_space et access_range
 * detruire la team

Aspects encore flous :
 - comment realiser le bout de code qui fait return 0; et qui retourne
dans le thread fils via un IRET ? (on peut pas avoir un seul bout de
code comme ca pour tout le systeme, parce qu'il est different pour
chaque thread car l'adresse de retour est differente)
 - que faire lors d'un fork() pour les threads qui sont en attente
(waitqueue, sem, msg, signal, etc..) ? Faut-il que les fils soient aussi
en attente ? (par exemple un thread d'une team bloque sur un read(),
tandis qu'un autre thread fait fork())

Eventuellement, pour que la demonstration soit plus convaincante :
 - un chtit printf en CPL3
 - appels systemes getpid() et getppid()

Le prof veut que je bosse completement differemment de notre maniere de
travailler : il veut que je cerne d'abord tous les problemes a resoudre,
que j'en fasse part dans un document de conception, puis qu'ensuite
seulement je realise.

Si vous avez des commentaires, ajouts, modifs a proposer, ca serait
sympa !

Merci bcp,

Thomas
--
thomas.petazzoni@enix.org - icq #34937744
Projet KOS : http://kos.enix.org
Club LinUT : http://club-linut.enix.org
Page Perso : http://www.enix.org/~thomas/