[Kos-dev] Re: Meditations de la journee

d2 kos-dev@enix.org
15 Apr 2002 18:15:26 +0200


Bonjour,

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@enix.org> writes:
    Thomas> Ceci dit, je suis pret a etudier toute proposition visant
    Thomas> a modifier l'existant. Je ne vois pas exactement comment
    Thomas> tu veux faire d2, pourrais-tu expliciter un peu plus ?

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.

    Thomas> Et sinon d2, le probleme des locks au niveau de
    Thomas> bbl_open_sr, tu en penses quoi ? Et dans l'ensemble mis a

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.

    Thomas> part les quelques remarques, que penses-tu du travail ?
    Thomas> Cela va-t-il dans le sens ou tu pensais que les choses
    Thomas> iraient ?

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").

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.

Avant la release, je pensais a 2 ou 3 trucs :
  - 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").
  - une autre option cmdline wolfgang, du genre init=/bin/init/test
    (+MAJ mineure testing*.tex en consequence)
  - (optionnel) un syscall read_console() qui lit caractere par
    caractere, et un readline() dans libc utile pour faire des tests
    sans rebooter.

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 ;)

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).

    Thomas> D'autre part, j'avais enleve le module ipc du CVS il me
    Thomas> semble, quelqu'un l'a remis ? (je l'avais peut etre mal
    Thomas> supprime, c'est possible).

Pas moi, enfin je crois pas.

Bonne journee,

-- 
d2