Projet système PC : 2017 - Nils Burlat, Pierre-Antoine Porte

De Ensiwiki
Aller à : navigation, rechercher
FlamencOS.png
Titre du projet FlamencOS
Cadre Projet système d'exploitation 2017
Page principale Projet_système

Équipe Pierre-Antoine Porte , Nils Burlat
Encadrants François Broquedis, Gregory Mounie, Patrick Reignier


Équipe

  • Nils Burlat (nils.burlat@gmail.com)
  • Pierre-Antoine Porte (porte.pierreantoine@gmail.com)

Introduction

Nous verrons sur cette page, comme indiqué dans les consignes https://ensiwiki.ensimag.fr/index.php?title=Projet_syst%C3%A8me#Attentes_.C3.A0_la_fin_du_projet

Plus précisément, nous allons décrire un journal de bord ainsi que les difficultés auxquelles nous avons été confronté pendant ce projet. Un planning prévisionnel et réel sera également mis en avant.

Cahier des charges

Tout est dans le wiki ---> Projet système : spécification

Gestion de projet

Outil de gestion de configuration

Nous avons utilisé le dépôt Git de l'école (Obligatoire). Nous avons créé des branches quand nous avons divisé le travail.

Planning

Notre Gantt réel diffère un peu du Gantt prévisionnel, c'est raisonnable à la vue de l'incertitude que nous nous étions permis vis à vis de ce programme. Cependant, deux changements sont notables et peuvent être commentés : la parallélisation de tâches dépendantes ainsi que la phase 4 "grisée" dans le Gantt réel où nous avons en fait refactorisé beaucoup de code pour valider les tests.

Parallélisation des tâches

Quelques tâches (ou phases) ont été réalisées en parallèle sur une durée maximale d'une journée, ou une journée et demie. Une fois le début d'une phase implémentée, nous pouvions parfois répartir le travail et avancer sur différentes fonctionnalités séparément (bien que le pair programming s'est révélé extrêmement utile sur ce projet qui nécessite plus de compréhension que de capacité à coder efficacement et rapidement). Nous avons donc pu avancer la phase 4 pendant que quelques tests étaient entrain d'être corrigés (validation des tests). Lorsque nous étions un peu bloqué en phase 5, nous avons aussi pu commencer à implémenter la console avec les interruptions clavier, qui étaient indépendantes du mode user jusqu'à l'appel de l'interruption 49. Finalement, en prioritisant les phases précédentes et en pouvant avancer un peu sur les phases suivantes, nous avons pu maintenir un rythme de développement conséquent tout en s'assurant de ne pas être bloqué sur une fonctionnalité potentiellement requise pour la suite du projet.

Validation des tests

Nous sommes arrivés en milieu de phase 4 à essayer de faire valider les tests fournis dans le répertoire user. Nous n'avions presque aucun test qui passaient, et nous avons donc dû refactoriser beaucoup de code, revoir certaines implémentations, et surtout adapter quelques petits changements pour que les tests passent correctement. Ce travail aurait du être fait au fur et à mesure et nous aurions du baser notre implémentation sur ce qui était attendu par ces tests. Nous avons perdu un peu de temps à faire cela, mais c'était nécessaire pour la suite du projet (mieux vaut tard que jamais !). La phase 4 était la phase la plus longue car elle a nécessité beaucoup de debug et par conséquent de changement et temps, notamment pour le test 13. Finalement, notre code a été fonctionnel à partir de ce moment là, et il l'a été pour toutes les fonctionnalités suivantes.

Gantt prévisionnel

FlamencOSGantP.png

Gantt réel

FlamencOSGantR.png

Journal de bord

Jour 1 - 8 juin

  • Découverte du projet
  • Découverte de la spécifications, des manuels sur Ensiwiki
  • Mise en place d'un script pour automatiquement : compiler, afficher l'erreur si il y en a, sinon lancer QEmu. Option "debug" pour démarrer GDB.
  • Gestion de l'affichage : implémentation des fonctions nécessaires

Jour 2 - 9 juin

  • Mise en place de la structure processus
  • Démarrage des processus
  • Ecriture de la function "ctx_sw"
  • Mise en place de l'interruption de l'horloge et appel de "ctx_sw" à intervalles réguliers

Jour 3 - 12 juin

  • Changement de contexte valide entre deux processus, mais pas plus.
  • Découverte d'un problème bloquant à l'affichage du caractère '\n'

Cette journée a été compliquée, nous avons passé des heures entières sur ce bug. Et nous n'avons pas trouvé la source du problème...

Jour 4 - 13 juin

  • Désactivation de l'affichage de '\n'
  • Changement de contexte fonctionnel pour n processus
  • Début des primitives systèmes : getprio, chprio, getpid, exit, kill, waitpid
  • Mise en place de la gestion des fils d'un processus

Jour 5 - 14 juin

  • Utilisation d'une file pour déterminer le processus prioritaire
  • Correction de bug dans waitpid
  • Suppression d'un processus mort de la liste des enfants de son père
  • Début de l'implémentation des primitives suivantes : pcreate, psend, preceive, pdelete

Jour 6 - 15 juin

  • Fonctions liées à l'horloge : wait_clock, current_clock, clock_settings
  • Continuation de l'implémentation des primitives de file de messages
  • Création de quelques tests personnels
  • Test de notre noyau à l'aide des tests fournis : découverte de multiples bugs

Jour 7 - 16 juin

  • Modification des enfants d'un processus : utilisation d'une file au lieu d'une liste chaînée maison
  • Continuation de l'implémentation des primitives de file de messages
  • Mise en place d'une architecture solide pour lancer les tests
  • Correction de multiples bugs trouvés grâce aux tests fournis

Jour 8 - 19 juin

  • Ajouts de tests personnels pour les primitives de file de messages
  • Fin de l'implémentation des primitives de file de messages
  • Correction de multiples bugs trouvés grâce aux tests fournis

A partir de ce jour, les 12 premiers tests fournis fonctionnaient correctement.

Jour 9 - 20 juin

  • Début de la phase 5 (mise en place du mode utilisateur)
  • Ecriture du code assembleur pour l'interruption 49
  • Debug du test 13 : découverte de multiples bugs dans les primitives de file de messages
  • Correction des bugs dans les primitives de file de messages

Jour 10 - 21 juin

  • Ecriture de la librairie d'appels systèmes : libc
  • Ecriture de la récupération des appels systèmes dans le noyau
  • Début de l'écriture de la fonction "jump_usermode"
  • Création de la pile utilisateur dans la structure processus
  • Fête de la musique

Jour 11 - 22 juin

  • Retour usermode->kernel fonctionnel
  • Accès à la valeur de retour des appels systèmes
  • Gestion des erreurs défaut de page et défaut général

Jour 12 - 23 juin

  • Appel système pour utiliser "printf" en mode user
  • Début des interruptions clavier
  • Fonctionnement correct des tests fournis en mode utilisateur
  • Début de l'implémentation de "cons_read"

Jour 13 - 26 juin

  • Appels systèmes pour changer les couleurs de la console
  • Début du processus shell
  • Création de l'environnement du shell : affichage de la date, de l'heure, d'un header, d'une page d'accueil...
  • Parser pour analyser les arguments des commandes tapées au shell
  • Implémentation de commandes pour le shell : ps, kill, sleep...

Jour 14 - 27 juin

  • Ajout de commandes pour le shell : test (lance les tests), man, exit, echo, date, clear
  • Démarrage de chaque commande dans un processus
  • Ajout de la gestion du CTRL+C
  • Larmes de fin de projet

Réalisations & extensions

Finalement, un shell minimaliste tourne sur FlamencOS. Différentes commandes ont été réalisées en extension, nous n’avons en effet pas choisi de rajouter différents affichages en ASCII qui n’apportaient pas énormément de valeur. De plus aucune démonstration de C n’a été réalisée. Notre shell est donc capable de répondre aux commandes suivantes :

  • clear
  • ps
  • exit
  • sleep
  • kill
  • test
  • ctest
  • man
  • echo
  • date
  • why

Chacune de ces commandes peut de plus être lancée en background avec l'ajout du paramètre '&' à la fin des arguments. Pour ce qui est des commandes lancées en foreground, elles peuvent être stoppées via un CTRL+C.

Difficultés rencontrées

  • Phase 2 : Lors du jour 3, nous avons eu un énorme problème qui nous a couté une journée. En essayant le code que nous testions sur le projet de personne déjà en phase 3, c’était simplement un soucis de printf \n qui nécessitait une stack importante, et nous ne donnions que très peu d’espace au processus lancé. Le problème était donc juste un problème de compréhension de la stack et non d’implémentation, et cela nous a couté un jour entier de développement, si ce n’est plus.
  • Phase 4 : Nous avons du refactorisé notre code entièrement (ce qui était une très bonne chose) non pas par une erreur d’implémentation mais probablement plus à cause de l’illisibilité de ce code qui avait été fait « à la va vite ». Nous avons du travailler sur l’envoi de message et la réception lorsque les processus était bloqué lors du test 13. Cela nous a pris beaucoup de temps et nous avons su apprécier la réflexion sur papier que nous avons été obligé de mener.
  • Phase 5 : Concernant la séparation du mode kernel et du mode user. Cela ne demande finalement pas beaucoup de code, mais plutôt beaucoup de compréhension. Or les informations sont dures à trouver sur le wiki, il a fallu se tourner vers une documentation externe : OsDev [1]. L’apport du professeur vis à vis de ce que nous devions écrire dans la pile en assembleur ou en C a été grandement utile. Nous avions notamment écrit du code en assembleur peu compréhensible que nous pouvions finalement écrire en C (lors de l’iret simulé pour jumpé en ring3).
  • Debug : Avec peu de documentation sur gdb ou d’indice sur comment l’utiliser nous avons eu du mal à nous en servir. Suite à l’intervention de plusieurs professeurs pour nous aiguiller sur le problème nous avons découvert des commandes dont nous n’avions à l’origine pas connaissance.

Appréciation du projet

Ce projet nous a beaucoup plus, à la fois grâce aux réflexions que nous avons eu besoin de mener durant l'implémentation et également grâce aux compétences que nous acquises en système d'exploitation. De plus, le fait de réaliser une fonctionnalité supplémentaire sur notre projet parti de quasiment rien est très satisfaisant. Nous avons été très heureux de découvrir comment est codé un OS et d'en réaliser une version minimaliste nous-même.

Flamenco.jpg