Rework report

rapports/td2/rapport.md

@@ -49,6 +49,7 @@ pouvons passer qu'une seule valeur lors de du démarrage de notre Thread:
 ```c
 Thread->Start(void * funtion, void * arguments) 
 ```
+\newpage
 
 Nous avons choisi d'encapsuler l'adresse mémoire de la fonction et l'adresse
 mémoire de ses arguments dans une structre `ThreadArgs_t`:
@@ -65,23 +66,24 @@ Celle-ci est effectuée dans le fichier d'entête `userthread.h`, nous parlerons
 de `int stackAddr` un peu plus loin dans ce chapitre.
 
 La fonction `StartUserThread`, servant à initialiser les différents registres,
-reçoit cette structure sous la forme d'un `(void*)`. Nos ne pouvons l'utiliser
-tel quel, il nous faut donc la caster dans une variable de type `ThreadArgs_t`.
+reçoit cette structure sous la forme d'un `(void*)`. Nous ne pouvons utiliser
+cette structure avant la caster dans une variable de type `ThreadArgs_t`.
 
 Afin de ne pas perdre cette structure lors de la fin de notre fonction
 `Do_ThreadCreate`, nous la positionnons sur le tas avec un `malloc`
 (`userspace.cc` ligne 50). Afin de ne pas froisser *LealSanitizer* nous n'avons
-pas oublié de libérer cette zone mémoire une fois devenueNouveau dossier inutile dans la
-fonction `StartUserThread` (ligne 38-39).
+pas oublié de libérer cette zone mémoire une fois devenue inutile
+dans la fonction `StartUserThread` (fichier `userthread.cc` ligne 38-39).
 
 ### Le comptage des thread.
 
-Comme nous l'avons compris, la classe `AddrSpace` représente un processus -- un
-espace d'adressage. Côté noyau, tout n'est que Thread, dont certains partagent
-un même espace d'adressage. Il nous a donc **semblé légitime d'implémenter le
-comptage des Threads  dans `AddrSpace`** via la variable publique `int thread`
-(définie dans `addrspace.h` ligne 50). Celle-ci est initialisée à 1 lors de
-l'instanciation: le `main` de notre programme compte lui aussi pour un thread.
+Telle que nous l'avons comprise, la classe `AddrSpace` représente un processus
+-- un espace d'adressage. Côté noyau, tout n'est que thread, dont certains
+partagent un même espace d'adressage. Il nous a donc **semblé légitime
+d'implémenter le comptage des threads  dans `AddrSpace`** via la variable
+publique `int thread` (définie dans `addrspace.h` ligne 50). Celle-ci est
+initialisée à 1 lors de l'instanciation: le `main` de notre programme compte lui
+aussi pour un thread.
 
 Une fois que nous savons combien de threads sont encore "en vie", il nous est
 possible de terminer notre programme quand tous ses threads sont finis dans la
@@ -90,7 +92,7 @@ fonction `Do_ThreadExit` (fichier `usersthread.cc` ligne 88).
 ### Gestion de la pile
 
 Comme l'a démontré notre programme de test (`/test/threadtest.c`), la première
-version de notre gestion de threads  était plus qu'imparfaite: elle les
+version de notre gestion de threads était plus qu'imparfaite: elle les
 conjuguait tous avec la même pile. Nous avons alors utilisé la classe `Bitmap`
 afin de gérer les espaces de pile de nos différents threads. Sachant que nous
 réservons 256 octets de pile par thread et que notre pile gérée par `AddrSpace`
@@ -141,6 +143,8 @@ convient pas (`Do_ThreadExit`), nous la trouvons bancale, une version plus
 élégante devrait être possible (sûrement plus simple une fois le TD3 plus
 avancé).
 
+\newpage
+
 ## Tests
 
 Tous nos test se sont fait avec `test/threadtest.c`, nous avon adapté son code
@@ -149,4 +153,7 @@ en fonction de ce que nous voulions tester:
  * tester le fonctionnement d'un seul thread (Action I.7)
  * tester le fonctionnement de plusieurs threads (Action II.1)
  * tester la pile (Action II.3)
- * l'utilisation de la classe `Bitmap` (Action II.4) 
+ * l'utilisation de la classe `Bitmap` (Action II.4)
+
+Nous avons aussi inclus en ensemble conséquent de message de debug afin de
+tracer les actions de notre implémentation.