6.5 KiB
title: systèmes d'exploitation, TD1 documentclass: scrartcl author:
- Cédric Cassin
- 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
Ce premier TD est notre première approche de Nachos, et il faut bien avouer qu'il ne fut pas aussi mélodieux que le premier contact dans Rencontre du Troisième Type de Steven Spielberg.
Nous qui sommes sortis de la licence ADSILLH 1 disposons un avantage sur certains de nos autres camarades: nous avons eu des cours (et TDs) sur les appels systèmes GNU/Linux. Nous avons aussi un handicap : nous sommes inscrits en Master IDI, ce qui signifie que nous avons une vie professionnelle en plus de notre vie étudiante. En gros moins de temps personnels à consacrer à Nachos.
Nachos n'en reste pas mois un sujets intéressant -- bon effectivement nous n'en ferons pas notre dernière vague tel Patrick Swayze dans Point Break -- mais developer ces premiers appels systèmes fut un travail enrichissant.
Ce qui manque
Comme vous pouvez l'imaginer après avoir lus les lignes précédentes, nous
n'avons pas eu le temps d'implémenter un élément : printf manque à l'appel au
moment où nous écrivons ces lignes2.
Nous avons aussi implémenté la gestion des erreurs de mémoire dans les fonctions
copyStringFromMachine et copyStringToMachine, ces fonctions retourne -1
si une erreur se produit dans les instructions ReadMem et WriteMem (elles
retourne alors false), mais nous n'avons pas implémenté la gestion de ce
cas de figure dans les appels PutString et Getstring.
Ce que nous avons
Nous avons implémenté PutChar, PutString, GetChar et Getstring.
Nous sommes globalement satisfait du code que nous avons produit. Cependant des
doutes subsistent sur l'implémentation de Getstring.
Nous avons aussi écrit les fonctions CopyStringToMachine et
CopyStringFromMachine que nous avons positionné dans le fichier
userprog/exception.cc. Ces deux fonctions pourraient en effet servir pour
d'autres appels système.
Les bugs
A part un bug lors de la compilation de notre source de test pour l'appel
système PutString, nous n'avons pas repérés de bugs sur nos différents ajouts.
Ce qui ne signifie pas pour autant qu'il n'y en ai pas, mais les différents
tests mis en place n'ont pas révélés de problèmes particuliers.
Le problème avec notre test de PutString (le source est dans
test/pustring.c) se produisait à la compilation. d'après nos constatation, il
semblerait que si la chaine de caractère passées en paramètre est inférieure à
la taille du tampon (MAX_STRING_SIZE), alors l'erreur suivante apparaît à la
compilation:
putstring.c:(.text+0x10): dangerous relocation: Réadressage relatif GP utilisé alors que GP n'est pas défini
La fonction semble pourtant fonctionner correctement puisque nous l'utilisons
dans le source servant à tester GetString et ce quel que soit la taille du
texte saisi.
Mais cette erreur abordée sur le chat de l'UE a été réglée grace au conseil de
Samuel Thibaud de rajouter une option dans le Makefile du dossier test/.
Les points délicats.
Nous exagèrerions juste un peu en disant que tout le TD fut un point délicat... Il nous a fallut du temps pour comprendre comment les différents éléments s'imbriquent pour former un tout cohérent et les ceux à modifier pour ajouter ce qui était demandé3. Certaines modifications nous ont parfois explosées (virtuellement) au visage, un peu comme certaines inventions de Data dans Les Goonies.
Le point le plus délicat fut tout de même l'écriture de l'appel système
GetString. Il a nécessite beaucoup d'aller retour compilation / test /
modification un peu à la manière d'un jeu-vidéo de type Rogue-Like (aucune
manette de jeu, clavier ou souris a été blessé ou même malmené durant ce
TD...).
Afin de progresser sur cette partie, nous avons ajouté des DEBUG dans notre
code. Ainsi nous affichons tout un tas d'informations utiles.
Ces différents retours nous on permit de régler les problème que nous avions
dans les fonctions CopyStringToMachine et ConsoleDriver::GetString, mais
aussi améliorer globalement notre code.
Limitations
Dans notre appel GetString, il est possible de passer une adresse mémoire vers
une chaine de caractère plus grande que la taille donnée en paramètre. Si nous
avons réussi à obliger GetString à respecter le paramètre size en comptant
le nombre de caractères écrits, nos n'avons pas réussi à détecter ce cas de
figure pour éventuellement lancer une exception.
Un problème de sécurite peux alors se produite et il est simple à tester avec
test/getstring_2, le voici illustré :
/test@machine $ ./nachos -x ../test/getstring_2
12345678912345678ls
1234567891234567
[...]
test@machine $ ls
addrspace.cc bitmap.cc consoledriver.cc console.o
[...]
On voit bien que les caractères dépassant le tampon de 16 caractères on été
transmit à la console du système hôte de NachOS. dans notre test, un simple
ls a été effectué, mais un rm -rf ~ serait un peu plus problematique.
Nos différents tests sur le chaînes de caractères mettent aussi en lumière une limitation de NachOS : Il n'est pas très doué question caractères accentués, et a l'air de ne pas parler l'UTF-8 mais cette limitation n'est pas de notre fait.
Les tests
Pour PutString, nous avons écrit un petit programme permettant de tester
corriger un problème de caractère qui passait à la trappe lors du passage au tampon suivant.
Voici un exemple de sortie de cet appel avec la sortie de debug activée:
[...]
->copyFromMachine keycode:72
->copyFromMachine keycode:101
->copyFromMachine keycode:108
->copyFromMachine keycode:108
->copyFromMachine keycode:111
->copyFromMachine keycode:32
->copyFromMachine keycode:87
->copyFromMachine keycode:111
Read buffer:Hello Wo, size:8
Hello Wo
[...]
Pour GetString, nous avons aussi écrit un programme de test, celui-ci fait
une boucle infinie attendant une saisie utilisateur et la retranscrit grâce à un
PutString.