[Kos-dev] Premieres observations concernant les threads user (et autres)

[Thomas Petazzoni]

salut,

j'ai regarde un petit peu la doc intel pour voir comment ca allait se
goupiller ces threads user, et j'ai pu verifie une chose que je
craignais : le contenu de ce qu'on appelle le cpu_context_t est
different selon si le thread s'execute en CPL0 ou en CPL3.

la Figure 5-4, page 145 du volume 3 de la doc intel permet de bien s'en
rendre compte.

si on est dans un thread CPL0, et qu'une interruption arrive, alors les
choses suivantes sont empilees sur la pile : EFLAGS, CS, EIP et error
code.

si on est dans un thread CPL3, rien n'est empile sur la pile du thread
interrompu, mais les donnees sont empilees sur la pile du Handler. les
choses empilees sont SS, ESP, EFLAGS, CS, EIP et error code.

Deux problemes :
	1. comment merger les deux types de cpu_context_t ? je rappelle que ce
cpu_context_t est passe en argument a tous les handlers d'interruption,
on ne peut donc pas avoir un cpu_context_cpl0_t et un
cpu_context_cpl3_t, au niveau des types ca ne fonctionnerait pas. je
vois deux solutions : 
		a) on utilise un cpu_context_t qui contient les registres SS et ESP,
mais on les ignore si on sait que l'on est dans un thread noyau (de type
KERNEL_THREAD).
		b) on peut peut etre utiliser un truc genre une union, mais je suis
pas sur, et je doute que ce soit d'une utilisation tres pratique.

	2. pour que le thread tournant en CPL3 retrouve sa pile il faut mettre
a jour le TSS systeme, en modifiant les champs SS0 et ESP0. ce n'est pas
vraiment un probleme, mais il faut y penser.

Tout a fait autre chose : l'implementation de la memoire virtuelle par
SunOS propose de bien separer l'as (address space, espace d'adressage
virtuel) du hat (hardware translation layer). alors peut etre devrions
nous deporter toute la gestion de la memoire physique (mm/pmm.c) dans un
module mm-x86, qui serait en fait notre hat.

de toute facon il faut reamenager un peu ca, car dans mm/pmm.h on a la
definition de PAGE_SIZE, chose qui n'est pas portable et qu'il faut donc
deporter dans mm-x86/mm-x86.h.

qu'en pensez-vous ?

concernant le nommage des fichiers, il faudrait effectivement etablir
une sorte de standard. personnellement je pense que le modele de julien
(aka avoir un fichier par fonction, cf module babel ou module ipc) est
peut etre un peu excessif meme s'il est pratique (le fait qu'il soit
excessif reste toute fois discutable). separer le module en plusieurs
fichiers par theme me parait etre la meilleure solution. on pourrait
envisager un nommage du type : _nommodule_theme.c, un peu comme je l'ai
fais dans le module task. 

il faudrait de plus distinguer le .h prive (ce que j'ai fais par un _,
ou que fenix prefere faire avec un _private_) du .h public.

j'attends la aussi vos commentaires.

amicalement,

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