Projet système PC : 2015 - DURRENMATH Steven, GUNTZ Thomas, SELECK Thomas

De Ensiwiki
Aller à : navigation, rechercher
PepinOS.png
Titre du projet PepinOS
Cadre Projet système d'exploitation 2015

Équipe Steven DURRENMATH Thomas GUNTZ Thomas SELECK
Encadrants David Beniamine Gaëtan Morin Grégory Mounié


Présentation du projet

Le projet système a pour objectif l'implémentation d'un système d'exploitation bootable sur un machine nue d'architecture x86. II permet de mettre en œuvre plusieurs mécanismes vus en cours : synchronisation, concurrence, partage de tâche, temps réel...

Cahier des charges

Le détail des spécifications est accessible ici

Le projet est découpé en 7 phases :

  • Phase 1 : Prise en main de l'environnement de développement et gestion de l'affichage à l'écran.
  • Phase 2 : Notion de processus et le changement de contexte entre deux processus.
  • Phase 3 : Ordonnanceur : création dynamique, terminaison et filiation des processus.
  • Phase 4 : Gestion de la communication et de l'endormissement des processus.
  • Phase 5 : Séparation des espaces mémoire du noyau et des processus et ajout du mode utilisateur.
  • Phase 6 : Pilote de console.
  • Phase 7 : Invite de commandes.

Plannings

Les développements ont débuté le 11/06 et ont pris fin le 30/06.

Planning prévisionnel

Phase Temps estimé
Phase 1 1 jour
Phase 2 1 jour
Phase 3 2 jours
Phase 4 2 jours
Phase 5 4 jours
Phase 6 2 jours
Phase 7 2 jours

Planning effectif

Gantt-pepinos.png

Concernant la phase 5, il manque la protection de l'espace des entrées/sorties. La phase 6 n'est pas finalisée, et la phase 7 non implémentée.

Réalisation et difficultés rencontrées

Phase 1

Nous avons réutilisé et adapté du code des TPs du cours de SEPC de cette année et du cours de logiciel de base de l'année dernière pour réaliser cette phase.

Il a fallu également prendre en main l'environnement de travail :

  • Git : récupération de notre dépôt et création de nos branches de travail
  • Qemu : le simulateur permettant de tester notre système (avec vinagre)
  • gdb : pour le debug, il s'interface avec Qemu (via target remote)

Nous avons ajouté deux commandes dans le Makefile pour simplifier le lancement :

  • run : mode normal
  • gdb : mode debug

Phase 2

Cette phase peut être décomposée ainsi :

  • Notion de processus
    • mise en place de la structure des processus
    • création de processus
    • changement de contexte
  • Timer et interruptions
    • mise en place du traitant de l'horloge (IRQ0)
    • gestion du timer
    • affichage de l'heure

Des difficultés ont été rencontrées quant au choix de l'implémentation des processus, ainsi qu'à la gestion des interruptions.

Phase 3

  • gestion de l'ordonnancement par le scheduler, et de la création dynamique des processus
  • gestion de la terminaison des processus
  • gestion de la filiation

Il a fallu comprendre le mode de fonctionnement de la pile du processus, par exemple trouver comment passer des paramètres à la fonction à exécuter et comment renvoyer la valeur de retour de cette fonction.

Phase 4

Lors de cette phase, les files de messages ont été implémentées. Elles ont été testées par le biais d'un anneau à jetons. La primitive wait_clock a également été implémentée.

Lors de l'implémentation des files de messages, nous avons implémenté nous-mêmes les files alors qu'il existait une implémentation toute faite dans le fichier queue.c. Le debug de notre implémentation nous a fait perdre du temps. Certains tests ont également été longs et difficiles à débugguer.

Phase 5

  • Protection mémoire
    • Switch vers le mode user
  • Appels système
    • Bibliothèques d'appels vers le noyau
    • Traitant de l'interruption 49
  • Protection d'éxecution (du code)
    • Isolation des piles noyau et utilisateur
    • Changement de niveau de privilège

La documentation pour cette phase est importante. Le debug a été d'autant plus difficile que l'on joue sur deux tableaux.

Phase 6

  • Gestion des événements clavier (IRQ1)
  • Implémentation des appels cons_read et cons_write

Cette phase n'est pas finalisée. Les interruptions clavier sont gérées mais les appels système ne sont pas entièrement fonctionnels.

Phase 7

Cette phase n'a pas été implémentée.

Bilan

La complexité inhérente à ce projet impliquait intrinsèquement une gestion de projet importante mais avant tout astucieuse. Les contraintes d'antériorité entre chaque tâche rendaient difficile la parallélisation de ces dernières. Il nous a donc fallu faire preuve d'une bonne organisation qui malgré tout n'a pas suffi pour terminer le projet dans le temps imparti.

Le principal apport de ce projet se situe dans la mise en pratique des concepts théoriques abordés durant les heures de cours magistraux des périodes 5 et 6.