[Kos-dev] Piles niveau noyau, gestion du fork()

[Thomas Petazzoni]

Salut,

> Je vois pas trop. Apres le fork(), a la fois le AS du pere et ses PT
> sont copiees vers le fils (pour l'instant, pas de COW sur les
> PT). Donc pour une page donnee, soit elle a ete mappee par le pere,
> auquel cas elle est mappee aussi dans le fils (cause memes PT) ; soit
> elle n'est pas mappee par le pere et alors ne l'est pas non plus dans
> le fils (cause memes PT). Donc si le fils fait un #PF, c'est que soit
> la page est mappee dans pere et fils (cause memes PT) mais les droits
> d'acces sont insuffisants (=> differenciation en utilisant rmap), soit
> que ni le pere ni le fils n'ont mappe la page (=> utilisation de la
> liste des VRs qui pointent vers la SR, afin de mapper la page ou il
> faut chez tout le monde, en particulier chez pere et fils). Bref, je
> vois pas en quoi il y aurait besoin de remonter la hierarchie
> pere/fils a quelque moment que ce soit.

Simplement que je pensais pas recopier comme un bourrin les PTs. Je
pensais qu'a chaque #PF on essayait de voir si la page etait deja dispo
quelque part, et que sinon on allait la chopper a la main.
Je sais pas quelle est la meilleure solution, ni si la mienne est
viable, mais si c'est le cas, ca eviterait peut etre de recopier tous
les PTs (alors qu'on risque de faire un exec apres).

> Oui. Avec des jolies listes de threads bloques en attente sur synchro
> (+ ptr vers la synchro), d'autres en attente d'un timeout, d'autres
> prets a etre executes => ie 3 listes (sans parler de priorite pour le
> moment) et 5 ou 6 etats fixes (meme si on rajoute d'autres mecanismes
> de synchro). Ca me fait penser que ca serait bien que mutex,
> semaphores, rwlock (qu'on n'a pas encore), kmsg et cie soient tous
> descendants (heritage structurel, pas de babel pour l'instant je
> pense) d'une structure commune : une synchro_t. Cette structure
> renfermerait le struct thread *thread_list de kwaitqueue/ksem (a
> generaliser dans : kmsg, signal, ...). Ca eviterait d'avoir a rajouter
> un etat dans l'enum state, et un membre de l'union dans thread_t a
> chaque fois qu'on rajoute un mecanisme de synchro. Et pour le
> scheduler, c'est beaucoup plus systematique : pop de la liste des
> ready si y'en a ; sinon idle.

Y'a effectivement deja quelques listes de threads en attente (sem, wait
queue et sleeping), mais faudrait ptet essayer de generaliser tout ca
(pas besoin de Babel). Met tout ca dans le TODO, c'est pas trop dur a
faire, un jour ou je m'embete ;)

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