Projet système PC : 2016 - BOULANGER Adrien, GOMES Grégoire, DE VALON Hugues

De Ensiwiki
Aller à : navigation, rechercher
SaltOS
PJSalt2.jpg
SaltOS (Super Amazing Lovely Terminal OS)

Développeurs Adrien Boulanger
Grégoire Gomes
Hugues de Valon

Présentation

ScreenshotSALTOS.png

Nous sommes trois étudiants de la filière SLE :

- Adrien Boulanger
- Grégoire Gomes
- Hugues de Valon.

Le cahier des charges est découpé en 7 phases distinctes du projet :

1 : Affichage à l'écran.
2 : Création des processus et changement de contexte
3 : Ordonnancement des processus.
4 : Files de messages et endormissement des processus
5 : Séparation des processus et du kernel en mode utilisateur et superviseur ET Gestion de la mémoire virtuelle pour le mode utilisateur.
6 : Pilote de clavier
7 : Création d'un shell

Les trois premières phases sont implémentées en important et modifiant le code produit pendant les TP de Pratique du Système.

Gestion de Projet

Planning Prévisionnel

PlanningPrevisionnelSaltOS.png


Au départ, nous avions le découpage suivant, 1 semaine pour les 4 premières phases. Puis une semaine pour la phase 5 compte tenu de sa difficulté, suivi de 3 à 4 jours pour les deux dernieres phases. Ceci nous aurait permis d'avoir la dernière semaine (lundi au jeudi) pour les extensions et le peaufinage de notre SaltOS.

Planning Effectif

PlanningR33lSaltOS.png

La première semaine s'est déroulée à peu près comme prévue, les trois premières phases étant des adaptations du cours de pratique du système. La quatrième phase a pris bien plus de temps que prévue mais c'est car nous avions une personne dédiée à celle-ci pendant que deux autres faisaient la phase 3 puis la phase 5.

C'est sur la phase 5 que nous avons eu le plus de difficulté avec de nombreux bugs très difficiles à identifier et éliminer. Une fois que nous nous sommes rendu compte de cela, nous avons dédié une personne à la phase 6 qui a aussi pris plus de temps que prévue à cause d'une mauvais compréhension de la spécification.

Ainsi, nous n'avons pas eu assez de temps pour des extensions intéressantes et nous sommes concentrés sur le peaufinage du projet et sur la réalisation de la documentation.

Phases de développement

Phase 1

Cette phase consiste à afficher à l'écran et prendre en main l'environnement.

Il n'y a donc pas de difficulté car importer le code console du projet PSE est immédiat, et elle consiste donc à lire le code fourni et la documentation pour s'approprier le projet.

Phase 2

Cette phase consiste à créer des processus et changer le contexte de façon manuelle dans ces processus. Encore une fois, une adaptation simple du code de PSE permet de faire fonctionner cette phase.

Phase 3

Cette phase consiste à importer la politique d'ordonnancement de PSE en ajoutant plus d'états possibles des processus et en rajoutant les structures de données nécessaires dans lesquelles on stocke les processus. Ainsi que d'utiliser une file de priorité (fichier shared/queue.h fourni) des processus prêts pour aider à l'ordonnancement.

En plus de cela, il faut gérer la terminaison des processus et la création des processus coté kernel de façon dynamique (fonction start).

Phase 4

Cette phase inclut deux choses :

- les files de messages qui sont le gros de cette phase

- l'endormissement des processus par l'appel système wait_clock().

Les files de messages sont assez complexes car la spécification n'est pas claire sur certains points de fonctionnement des files de messages. Dans ces cas là, il faut utiliser les tests 10, 11, 12, 13, 14 et 16 fournis pour vérifier l'accord avec les spécifications des files de messages. (Par exemple, comment gérer les processus réveillés après bloquage), peut-être délicat.

Nous avons en réalité laissé la phase 4 sans passer les tests 13 et 16 dans un premier temps puis nous avons corrigé cela à la fin du projet lors du peaufinage.

Pour wait_clock, attention car le paramètre à passer est absolu et non pas relatif, ce qui n'est pas forcément évident (et surtout pas logique).

Phase 5

Pour la phase 5, la première difficulté est de réussir à réunir la documentation car celle-ci est particulièrement éparpillée.

Pour avoir une vision générale de cette partie et quelques indications techniques nous vous invitons à consulter cette autre page wiki:

Projet système PC : 2014 - BISEGNA Tony, DENNEMONT Fabien et PACALET Xavier


Quelques problèmes rencontrés et conseils:

-Si on déclare un tableau en assembleur x86 la balise vaut la première case ainsi pour le manipuler "normalement" il faut prendre l'adresse de celle-ci.

-Quand vous rajouterez les pages partagées, n'oubliez pas de changer la gestion des de la libération de celle-ci.

-Encore les pages partagées: la clé de la page doit-être stocké dans la structure de donnée de celle-ci car la clé original se trouve dans la pile du processus initial et les autres processus ne peuvent donc accéder à celle-ci.

Phase 6

Cette phase consiste à gérer les entrées clavier.

La spécification (et certains profs) ne sont pas clairs sur cette partie.

Le moyen le plus simple pour gérer le buffer clavier est :

- de tout stocker (même entrée) dans le buffer clavier, et de supprimer directement les caractères lors d'un appui sur backspace. - de filtrer dans cons_read le caractère entrée contenu dans le buffer clavier. - ajouter un compteur d'entrées permettant d'appuyer sur entrée meme quand le buffer est plein.

Dans cons_read, il faut d'abord lire le buffer clavier au cas où quelque chose est contenu. Si on trouve un entrée, on retourne sinon on se bloque.

Le traitant d'interruption clavier débloque cons_read après un appui sur entrée, puis cons_read lit à nouveau le buffer et filtre le caractère entrée.

Nous avons choisi d'ignorer les tabulations, préferant garantir la cohérence affichage et buffer (la suppression des tabulations étant compliqué à mettre en oeuvre graphiquement).

Nous n'avons pas non plus gérer les flèches par manque de temps, mais l'ajout de ceci ne devrait pas être trop compliqué en utilisant un pointeur vers la case du buffer où se trouve le curseur et en utilisant memmmove pour insérer des caractères au milieu d'un mot. La partie compliquée doit d'être de réafficher la ligne courante entièrement à chaque insertion ou déletion au milieu de la ligne.

Phase 7

Nous avons appelé notre shell : M'Shell (prononciation : /mɪˈʃɛl/ (Michelle en anglais)) car il faut toujours respecter le shell (comme une dame / M'Lady).


Commandes disponibles :

- help: affiche la liste des commandes
- ps  : affiche la liste des processus et leur états
- start  : démarre un processus
- testXX + autotest : lance le test XX ou tous les tests (autotest).
- kill  : tue le processus dont le pid est passé en argument.

Extensions

N'ayant eu que 2 jours pour travailler sur les extensions, nous avons tenté d'implémenter le système de fichier FAT16

Les fonctionnalités de base sont: cat / ls / touch / write

Conclusion

Nous avons appris des choses.