134 lines
5.3 KiB
Markdown
134 lines
5.3 KiB
Markdown
---
|
|
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.
|