[Kos-dev] Re: Meditations de la journee

[Thomas Petazzoni]

Salut,

> J'ai dit que j'etais embete, donc je sais pas comment faire ;). Ah, au
> fait : mon probleme, c'est une histoire de *nommage* des champs. Car
> je suis tout a fait conscient que la separation vmm_drv/translator est
> necessaire (ou, du moins, plus elegante). Mais en l'etat, ca manque de
> symetrie (niveau nom), ce qui amene a se poser la question : "pourquoi
> pas tout mettre dans translator" (ou vmm_drv). Alors qu'on devrait pas
> se la poser, la question : ca devrait couler de source en voyant
> qu'une SR est liee a 2 choses pas mal distinctes, a savoir babel et
> vmm, et que separer les methodes en 2 sous-groupes distincts, c'est
> plur propre.

Je vois tjs pas vraiment ce qui te gene, mais ce qui est sur c'est que
les methodes Babel classiques doivent rester au niveau de l'interface.
C'est primordial, sinon ca n'a plus aucun sens. Par contre, je pense
qu'il serait bon de garder vmm_drv au niveau de la shadow resource,
parce que pour les SR /dev/mem/zero (qui ont toutes le meme translator),
on peut imaginer avoir deux vmm_drv : un peu pour les VR en MAP_PRIVATE
et un pour les VR en MAP_SHARED.

> Je note le meme pb que vous dans je_sais_plus_quelle_fonction
> (peut-etre bien bbl_open), ou l'ordre de lock/unlock entre sr et
> sr->parent_sr n'est pas symetrique dans le parcours de l'arbre. Ca me
> chagrine tout comme vous, mais je n'ai pas encore reflechi a la
> question.

Bin l'ordre de lock/unlock n'est pas symetrique, mais suis une logique :
1 on locke le parent
2 on cherche le fils
3 on lock le fils
4 un delocke le parent
5 parent <- fils
6 goto 2

Bref ceci marche tant que l'ordre de descente dans l'arbre est le meme.
Si on s'amuse a faire un truc qui locke fils, puis parent, et remonte
ainsi dans l'arbre, la c'est clair que c'est mort de chez mort.

Mais en imposant l'ordre de lock dans ce sens la, je pense pas que ca
pose trop de probleme. y'avait la solution du "on bloque toutes les SR
de tout le systeme", mais alors niveau granularite en SMP, on est nul.

> Oh voui, tout a fait. Maintenant je suis synchro avec votre
> terminologie babel (ie c'est comme la traduction en euros, j'arrive de
> mieux en mieux a squizzer l'etape de traduction "classe de
> service=interface, service=translator").

C'est en implementant qu'on se comprend. On a essaye de parler pendant
des heures de Babel, mais finalement c'est tellement abstrait, et comme
ni Julien ni moi n'avons vraiment de competences en objet, on
n'utilisait peut etre pas la terminologie adaptee.

> Y'a des trucs bien chiants qu'il va falloir regarder de plus pres :
> j'ai vu qqs race conditions dans tower (autre que bbl_open). Et sinon
> quelques petits oublis de strdup sont peut-etre encore a regler. Mais
> pour l'instant (on est sur du UP/1 team), moyennant les strdup a
> revoir a la loupe, tout ca parait mur pour la release.

Euh on a pas une team, on en a deux. La kernel_team, qui contient tous
les threads noyau, et une autre team, qui contient un thread noyau qui
lance un thread user puis se termine. A ce propos, je pense qu'il va
etre necessaire d'avoir un thread noyau par team, au niveau des IPC par
exemple ca peut etre vachement utile.

>   - un syscall write_console() pour que l'appli envoie un "coucou" sur
>     la console (tres hype le coup du thread cpl3 qui dit "hello world").

Ouais, un debut d'embryon d'oeuf de larve de driver TTY donc ;)

>   - une autre option cmdline wolfgang, du genre init=/bin/init/test
>     (+MAJ mineure testing*.tex en consequence)

Eventuellement.

>   - (optionnel) un syscall read_console() qui lit caractere par
>     caractere, et un readline() dans libc utile pour faire des tests
>     sans rebooter.

Ca reste dans la continuite du driver de TTY, que j'envisageai plutot
pour la prochaine release.

> Le premier, c'est pour faire le grand show de la mort quand les mecs
> bootent kos. Le 2eme, c'est parce que si le mec recupere l'appli de
> test et la disquette de boot par [snapshots], mais si il veut pas
> mettre le test dans /bin/init/, il l'a dans l'os. Le 3eme, c'est pour
> anticiper le debug de fork() qui demandera surement pas mal de mises
> au point en tous genres ;)

Je suis d'accord sur tous les points.

> Le 1er et le 3eme, je pense que ca devrait etre du quick and dirty de
> chez quick and dirty pour le moment (pas la peine d'avoir une SR
> console).

Oula, alors vraiment gore de chez gore, humm aime pas trop ca moi.

Bonne journee,

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