---
title: systèmes d'exploitation, TD3
documentclass: scrartcl
author:
 - Juliette Lenoir
 - Yorick Barbanneau
fontsize: 13pt
mainfont: DejaVu Serif
geometry: [top=1.5cm, bottom=3cm, left=3cm, right=3cm]
header-includes:
 - \definecolor{liens}{HTML}{de6a66}
urlcolor: liens
linkstyle: bold
...

## Bilan

Le voici, le boss final de Nachos: le dernier TD! Dans la lignée des précédents,
a-t-il fait passé un boss de Sekiro pour un promenade de santée? La réponse est
non. Profitant de l'expérience des précédents, nous sommes rentrés dedans plus
facilement. Mais ne pensez pas pour autant qu'on a fait une partie de Rayman,
<Plug>_comme pour les précédents, nous avons du y passer beaucoup de
soirées...

### La classe PageProvider

Nous avons implementé et utilisé sans trop de difficulté `ReadAtVirtual()` comme
demandé (*Action I.3*). La classe `PageProvider` implementée dans le
fichier `userprog/pageprovier.cc` n'as pas montré plus de difficulté non plus (
*Action I.5*).

Il a éte plus compliqué de choisir l'emplacement de notre variable
`pageProvider`. Nous avons au départ choisi de le positionner dans
`machine/machine.cc`. Mais comme on s'interroge souvent sur *La grande question 
sur la vie, l'univers et le reste*, on s'est aussi interrogé sur la pertinence
de cet emplacement. Nous avons fini par le positionner dans `threads/system.cc`.


Cette classe gère l'allocation de pages mémoire, il n'en faut qu'une seule
instance de cette classe, **nous devons gérer la mémoire que d'un seul 
endroit**. Plusieurs instances de cette classe entrainerai des collisions :
deux objets pourraient allouer la même zone mémoire.

#### La stratégie de test

Afin de tester notre implementation, nous avons écrit le programme
`test/userpages0.c`. Celui ci lance deux thread utilisant `PutString` pour
afficher des caractères. Nous nous sommes aidé d'information de débogage
donnée par la commande `DEBUG` afin de vérifier l'enchaînement des élements.
Afin de filter plus précisément les message issus de notre classe, nous
utilisons une lettre (p pour *PageProviser*):

```c
DEBUG ('p', "PageProvider: GetEmpryPage() allocated page: %i\n", newPage);
```

### L'appel système ForkExec

Le principe est donc simple : créer plusieurs espaces d'adressages, car encore
une fois, un processus est espace d'adressage. Nous avons maintenant de
l'expérience lorqu'il s'agit d'implementer des appels systèmes dans Nachos.

Nous avons choisi de mettre la fonction `do_ForkExec` dans le fichier
`userprog/userthread.cc`.  Nous avons géré deux problèmes possibles dans cette
fonction:

 1. Le fichier executable passé en paramètre n'existe pas
 2. La creation de l'espace dadressage échoue. Cette erreur doit être capturée
    avec un `try ... catch ...`

### Gérer les processus

Afin de gérer les processus, il faut les compter. Il nous faut donc un entier et
un sémaphore afin de protéger son incrémentation / décrémentation. Il sont
positionnés dans le fichier `threads/system.cc`.

L'incrémentation se fait dans le constructeur de `AddrSpace`, la décrémentation
dans son destructeur. Dans le destructeur, nous libérons aussi les pages
mémoire en exécutant ReleasePage sur chaque 
`AddrSpace->pageTable[]->PhysicalPage`.

#### Le test

Le programme `/test/forkexec.c` nous a servi de test pour notre implementation.
Il lance deux processus (`test/userpages0.c`). Le fichier `mempory.svg` exporte
dans la fonction `StartUserProc()` (`userprog/usertthread.cc` ligne *101*)
laisse bien apparaître nos **deux espaces d'adressages**.


### Le stress test

Nous avons écris le programme `test/forkexec_stress.c` qui fait appel à
`test/userpages0.c` et `test/userpages1.c`. Chacun des deux derniers est lancé
six fois (12 processus au total) et lance à son tours 12 threads.

Lors du lancement de ce stress-test, nous somme tombe à cours d'espace en
memoire. Nous avons donc augmenté le nombre des pages disponibles dans le
fichier `machine/machine.h`:

```c++
#define NumPhysPages    1024 // 256 pages au départ
```

Vous pouvez noter que la l'export de la cartographie memoire dans
`StartUserProc()` a été désactivé pour l'implementation de ce test. La
generation du fichier *SVG* allourdissait considérablement l'exécution. Nous
l'avons testé tout de même une fois: le fichier *SVG* pèse envison 18Mo...


## Ce qui nous manque

Nous n'avons pas eu le temps de traiter les points bonus. Nous avons une
ébauche de l'*Action II.4* sur notre dépôt de code mais rien ne fonctionne (à
vrai dire il est dans un `git stash` au milieu d'autres...).

## Les limitations

À partir de l'impementation de l'appel système `ForkExec`, l'*address sanitizer*
est désactivé. Chaque exécution d'un programme utilisateur contenant des thread
menait à des erreur de fuite mémoire. Cette erreur particulième nous contraint à 
effetcuer un CTRL+C afin de rependre la main sur notre terminal.

```
[...]
Cleaning up...
AddressSanitizer:DEADLYSIGNAL
=================================================================
==2622712==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 \
  (pc 0x7fdcc41a8227 bp 0x63100054cfb8 sp 0x63100054c688 T0)
==2622712==The signal is caused by a READ memory access.
==2622712==Hint: address points to the zero page.
```

Le temps nous a manquer pour investiguer sur le problème.