Projet système PC : 2015 - BOURGIER Mickaël, LAZZAROTTO Marcelin

De Ensiwiki
Aller à : navigation, rechercher
Titre du projet YoctOS
Cadre Projet système d'exploitation 2015
Page principale Projet_système

Équipe Mickaël Bourgier Marcelin Lazzarotto
Encadrants David Beniamine Gaëtan Morin Grégory Mounié


Présentation générale

Voici la page de présentation de notre OS nommé YoctOS, développé dans le cadre du projet système apprenti de l'Ensimag en 2015.

Nom du système

Le nom du projet viens de la terminaison OS (pour Operating System, système d'exploitation en anglais), ainsi que du préfixe du système international d'unités "yocto-" (https://fr.wikipedia.org/wiki/Yocto) qui correspond à une échelle de 10 exposant -24.

Nous disons donc avec amusement que notre système d'exploitation est vraiment tout piti.

Objectifs du projet

L'objectif du projet est, comme vous devez le comprendre, d'implémenter un système d'exploitation qui puisse fonctionner sur une machine physique. Le système développé est bien entendu extrêmement léger comparé aux systèmes existants (linux, windows...).

Il permet d'appliquer directement les connaissances vues en cours en gérant tout ce qui fait fonctionner un système ; depuis l'affichage à l'écran jusqu'à la gestion de la différence utilisateurs/kernel en passant par la gestion des processus.

La conduite du projet se fait en sept phases (décrites avec plus ou moins de précision ici : http://ensiwiki.ensimag.fr/index.php/Projet_syst%C3%A8me_:_roadmap) qui permettent la structuration du développement du système. Les phases et leur réalisations sont développées un peu plus par la suite.

Cahier des charges

Les spécifications complètes du projet peuvent être consultées sur la page Wiki correspondante : Projet système : spécification.

Nous avons terminé et testé tout ce qui était requis dans cette spécification. Notre OS est à priori entièrement fonctionnel. Aucune extension n'a pu être implémentée. Le shell gère toutefois quelques commandes supplémentaires par rapport à celles indiquées dans la spécification.

Fonctionnalités

Toutes les fonctionnalités requises demandées dans les spécifications ont été implémentées.

Tous les processus sont ordonnancés de sorte que l'utilisateur du système ait l'impression qu'ils s’exécutent simultanément pour des processus de même priorité. Nous pouvons lancer des processus en mode user isolés entre eux et ayant uniquement la possibilité de toucher à la mémoire user. Pour utiliser le système, les processus users peuvent faire des appels au système pour effectuer des actions particulières (affichage, actions sur les processus, etc.). YoctOS lance de lui même, au démarrage, un yoctoshell qui permet d'exécuter (en mode user) des commandes mineures.

Gestion de projet

Gestion des versions

Le dépôt initial du projet était fourni depuis les serveurs Git de l'Ensimag. Nous l'avons cloné pour commencer l'implémentation.

Afin de travailler depuis chez nous si nécessaire, nous avons choisi (car le VPN de l'Ensimag posait des problèmes sur nos machines personnelles) de créer un second remote pour stocker le projet sur un autre dépôt Git. Le dépôt était privé pour respecter la charte de l'Ensimag. Nous nous assurions toutefois de régulièrement push sur le dépôt Ensimag pour être certains que les commit étaient validés par le script.

Nous n'avons utilisé qu'une seule branche, master, pour faire des commit, principalement en conséquence de notre méthode de travail (voir sous-partie suivante).

Développement

Au départ, les primitives de chaque phase était nécessaires pour avancer. Nous avons par conséquent décidé de fonctionner en pair-programming en écrivant et faisant des commit à 2, en alternant le PC utilisé pour le développement.

Lorsque les tests fournis purent être lancés (phase 4) nous nous sommes séparé le travail en 2 : l'un poursuivant le développement du système, l'autre essayant de valider les tests relatifs à la phase traité précédemment et essayant de corriger le code écrit. Nous nous sommes parfois arrêté à 2 sur quelques bogues vicieux.

Bien que chaque phase dépende de la (des) précédente(s), le code d'une phase ne modifiait pas le code d'une phase précédente. Également, le code corrigé après les tests n'impactait pas le code d'une phase suivante. Nous avons donc pu travailler sans créer de branches dans le Git.

Planning

Outil de gestion : Trello

Nous avons utilisé Trello pour gérer les taches que nous effectuions pendant le projet. Nous avons pu nous organiser relativement efficacement avec cet outil.

Voilà une capture de ce à quoi pouvait ressembler l'organisation du projet pendant celui-ci (en cours de phase 4 sur l'image suivante).

PS trello screenshot.png

Diagramme de Gantt du planning effectif

Voici le diagramme de Gantt que nous avons effectivement suivi :

Bourgiem lazzmarc ps2a gantt.png

Détails des phases

Phase 1

Prise en main de l'environnement de développement et gestion de l'affichage à l'écran.

Implémentation

100 %

Tests

  • Les tests ont été réalisés en Logiciel de Base.
  • Quelques tests d'intégration au code fournis.

Détails

Nous avons pu réutiliser le code développé lors du module Logiciel de Base (module apprenti). Nous avons donc ainsi pu avoir une source solide et déjà testée (mais pas suffisamment, avons-nous découvert par la suite).

Difficultés

Aucune notable.

Apports

Gestion d'une zone mémoire bien particulière et cadrée (écran). Gestion de l'horloge (car faite également en LDB) : nous avons appris à gérer une interruption matérielle.

Phase 2

Notion de processus et le changement de contexte entre deux processus

Implémentation

100 %

Tests

Tests d'intégration rapide en utilisant l'affichage. Chaque processus devait afficher son PID à l'écran avec une alternance.

Difficultés

Quelques difficultés mineures sur la gestion de la pile de chaque processus, pour comprendre dans quel ordre empiler les informations nécessaires lors du démarrage.

Apports

Compréhension du fonctionnement d'un changement de contexte sur les systèmes d'exploitation.

Phase 3

Ordonnanceur : création dynamique, terminaison et filiation des processus

Implémentation

100 %

Tests

Tests d'intégration au code de l'étape précédente. Encore une fois, tests réalisés avec l'affichage à l'écran de la phase 1.

Difficultés

C'est à partir de cette étape que sont apparus les premières difficultés pour trouver des informations dans les pages éparses de la documentation. Nous nous sommes rendus compte en fin de phase que nous avions suivi des instruction sur certaines pages du wiki décrivant les opérations à implémenter qui différaient de ce qui était indiqué sur la page de conduite du projet.

Nous avions donc légérement anticipé sur la phase 4 (avec la fonction sleep()) et 5 (avec wait_clock()).

Quelques difficultés pour gérer la filiation mais rien d'insurmontable (quelques bogues facilement détectables).

Apports

Gain d'expérience, rien d'autrement plus notable.

Phase 4

Gestion de la communication et de l'endormissement des processus

Implémentation

100 %

Tests

  • Sur les tests globaux (17 sur objectif de 20 - mode user)
    40 %
  • Sur les tests passables à cette étape (17/17 - mode kernel)
    100 %

Également quelques tests additionnels à la main avant de lancer les tests fournis.

Difficultés

Quelques difficultés sur les files de messages pour gérer la synchronisation des processus, notamment avec des bogues difficiles à détecter. Une mauvaise compréhension de la documentation a également menées à revoir le travail effectué sur les fonctions psend() et preceive().

Apports

Nous avons une meilleure compréhension sur la façon dont un système moderne peut gérer la synchronisation des processus ainsi que la communication inter-processus.

Phase 5

Séparation des espaces mémoire du noyau et des processus et ajout du mode utilisateur

Implémentation

100 %

Tests

  • Sur les tests globaux (18 sur objectif de 20 - mode user)
    90 %
  • Sur les tests passables à cette étape (18/18 - mode user)
    100 %

Détails

Nous avons également eu à retravailler sur l'écran car quelques bogues imprévus étaient présents depuis le début sans que nous l'ayons remarqué.

Difficultés

C'est ici que sont apparus les plus grosses difficultés. Il fallait manipuler deux piles par processus pour gérer la séparation user et kernel, comprendre quels registres empiler et comment, comprendre comment utiliser les fonctions de terminaisons de programmes en mode user.

Tout cela alors que la spécification/documentation fournie est assez brouillonne à ce sujet. Nous avons été plusieurs groupes à nous entraider pour pouvoir terminer cette phase avec succès.

Apports

Nous comprenons maintenant comment un système d'exploitation est capable de gérer plusieurs niveaux de privilèges pour chaque processus, et comment sont gérés les appels systèmes.

Phase 6

Gestion du clavier (entrées/sorties)

Implémentation

100 %

Tests

19/20 - mode user

95 %

Difficultés

Aucune notable sur la gestion de l'interruption. Quelques difficultés mineures pour manipuler le buffer, mais rien d'insurmontable après les tests.

Apports

Nous avons compris comment fonctionne les entrées sorties pour un système d'exploitation. Nous pensons que la façon dont on nous a demandé de l'implémenter n'est pas forcément celle utilisée pas les OS actuels car nous pouvons nous en servir uniquement en mode console.

Phase 7

Gestion de l'interpréteur de commandes

Implémentation

100 %

Tests

20/20 - mode user
100 %

Nous avons corrigé un bogue d'une étape précédente qui nous a permis de passer le test 20.

Difficultés

Aucune notable.

Apports

Rien de particulier (nous avions fait un ensishell en TP).

Commandes et manœuvre(s) additionnelles

  • Commande clear  : efface l'écran
  • Commande info : affiche l’écran de démarrage contenant des informations sur YoctOS
  • Commande help : affiche la liste des commandes ou comment en utiliser une
  • Commande kill : tue un processus
  • Commande print : affiche un message à l'écran
  • Commande sleep x : fait une pause de x secondes
  • Commande test : lance un (passer le n° en paramètre) ou tous les tests (aucun paramètre)
  • Commande uptime : affiche le temps écoulé depuis le démarrage du système
  • Possibilité d'exécuter une commande en arrière plan grâce au caractère &