[Kos-dev] En vrac : sptree + doc www + alloc pile + VM + Bug IM + CREDITS

[d2]

Bonjour,

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@ifrance.com> writes:
    Thomas> regarder ca. si tu as le temps d2, tu peux le faire. j'ai
    Thomas> joint à ce mail deux implementations de splay trees (elles
    Thomas> sont tres semblables), et surtout un fichier drawtree.c

En fait, l'une d'elle apporte juste un champ size, dont on se fout un
peu. L'autre ajoute le champ "parent" ; ca correspond a la modif que
j'ai faite avec le champ "up". La 3e est la version originale de
splay_lib.c. Donc en fait, on va pas trop s'en inspirer. Ceci dit, si
un jour ca nous dit d'afficher les arbres, on a qu'a garder la 1ere
sous le coude.

    Thomas> salut, je vais essayer de me decider a mettre a jour le
    Thomas> site web. voici a mon avis les maj a faire :
    Thomas> 	- dans documentations.html : licence du projet, on met
    Thomas> que c'estla GPL et point ? 

Tu voudrais mettre quoi d'autre ?

    Thomas>  - dans documentations.html :
    Thomas> la doc sur l'install est un peu obsolete, est-ce que l'on
    Thomas> doit encore parler de la compilation sous windows ? a mon
    Thomas> avis, on peut juste signaler que ca doit etre faisable,
    Thomas> mais que l'on a pas teste.

On s'etait pas concerte pourtant, mais ca doit etre parce que les
grands esprits se rencontrent : j'ai justement mis a jour la doc
d'install. Le chapitre win32 est vraiment secondaire, mais je l'ai
laisse. Il est en fin de doc, et donc ca fait que la doc est plus
claire : on ne melange plus win32 et Unix comme avant. Y'a tout sur
unix, et qqs ficelles pour une install win32, bien a part.

    Thomas>  - acceder au cvs : dire que
    Thomas> maintenant pserver a marche pu, a pu que ssh

C'est en debut de la doc CVS (en gras).

    Thomas> salut, y'a un truc que je comprends pas, un detail doit
    Thomas> m'echapper.  quand on lance le primary thread, y'a pas de
    Thomas> pages physiques allouees pour sa pile. et on l'alloue
    Thomas> lorsqu'on fait un page fault. mais le handler du page
    Thomas> fault empile des trucs non ? donc normalement ca devrait
    Thomas> foirer... et on devrait avoir un double fault. pourtant ca
    Thomas> marche.

Ben non, parce que l'alloc de pile se fait avant de changer de pile
justement. L'alloc de pile se fait au moment ou on prepare la nouvelle
pile pour le "ret", ie quand on fait :

  *((unsigned*)(thread->context.esp_cpl0 + 0)) = (unsigned)kt;
  *((unsigned*)(thread->context.esp_cpl0 + 4)) = SEG_CODE_KERNEL_ID * 8;
  *((unsigned*)(thread->context.esp_cpl0 + 8)) = (unsigned)data;

c'est a dire dans init_kernel_thread_context() (task/task.c, aka "mal
place"), et un peu avant de faire le ret qui va bien.

Donc ca se passe bien, et c'est normal.

    Thomas> salut, j'ai pense a deux choses aujourd'hui :
    Thomas> 1. pour lancer le primary kernel thread, il faut faire un
    Thomas> IRET, et non un RET, c'est a dire qu'il faut en plus

Oui. On l'avait pas fait pour le 1er thread parce qu'il ne pouvait pas
y avoir de chgt de cpl/IF. Mais c'est vrai que pour le cas general des
chgts de contextes, il faudra iret.

    Thomas> 2. quand on va swapper une page physique, il va falloir la
    Thomas> demapper de tous les espaces virtuels ou elle est mappe il
    Thomas> me semble. c'est a dire qu'il va falloir modifier les PTs
    Thomas> de plusieurs taches... et il ne faudrait pas changer de
    Thomas> contexte ! de plus meme si la page n'est mappee qu'une
    Thomas> seule fois, mais qu'elle n'appartient pas a la team
    Thomas> courante, il faudra changer de contexte... et ca c'est
    Thomas> naze. d'autre part, dans la structure gpfme_t, il n'y a
    Thomas> rien qui nous permettent de remonter de la page physique
    Thomas> vers ses differentes adresses virtuelles (et donc les
    Thomas> differents PDE et PTE), afin de la demapper.  bref il faut
    Thomas> trouver une solution de ce cote la.

Pour le phys->virt, oui d'accord. A part la possibilite de changer le
mapping des autres threads en evitant de faire un gros scan de tous
les PD/PT des voisins (=> en se restreignant a leur Virtual Regions),
je vois 1 autre interet : quand on veut mapper du matos : il faudra
surement deplacer des pages pour qu'elles soient en dehors de la zone
physique du matos. C'est vrai que pour faire ca, il faudra pouvoir
determiner quelles pages virtuelles sont dans quelle zone physique.

Pour les modifs de pd/pt des autres teams qui imposeraient des chgts
de contexte, la par contre ca depend : il faudra s'assurer que tous
les pd/pt sont dans l'IM. A partir de la, on doit s'en sortir sans
changer de contexte. Et puis, faudra s'assurer de la meme chose pour
l'allocation des Virtual Region, je pense.

>>>>> "Julien" == Julien Munier <munier@wanadoo.fr> writes:
    Julien> Building identity mapping up to : 6 Mb

C'est vrai que j'avais teste avec un multiple de 4MB (8MB en
l'occurence). Je revois ca ce soir.

Sinon, je pense qu'il faudra rajouter un fichier CREDITS dans lequel
on citera nos sources d'inspiration :
  - bochs (parce que sans lui...)
  - gcc (pour stdarg.h)
  - D. Sleator (pour splay_lib.c)
  - Linux (pour vsprintf)
  - bochs/plex86 (pour disasm.[ch])

Ca avance tout ca !

Bonne journee,

-- 
d2