Projet système PC : 2016 - BUISSART Romain, KADAR Marine, MÉLOUX Maxime

De Ensiwiki
Aller à : navigation, rechercher
OS'Sature.png
Projet Système 2016

Développeurs BUISSART Romain
KADAR Marine
MÉLOUX Maxime

I Présentation

Bienvenue sur la page de présentation du système d'exploitation "OS'Sature" développé dans le cadre du projet de spécialité de deuxième année. L'objectif est de réaliser un noyau de système d'exploitation sur une architecture dédiée, à travers la gestion de la console, des processus, mémoire virtuelle et le temps.

Équipe

BUISSART Romain : Filière SLE
KADAR Marine : Filière SLE
MÉLOUX Maxime : Filière MMIS

Fonctionnalités

Notre système d'exploitation implémente les fonctionnalités décrites dans le cahier des charges ci-dessous.
Nous n'avons pas eu le temps d'implémenter d'extensions, si ce n'est les quelques lignes d'assembleur permettant au noyau de se lancer avec l'heure correcte du système (appel BIOS).

Notre OS (cliquez pour agrandir)

II Cahier des charges

Le projet est découpé en 7 phases :

  • Phase 1 : Affichage de caractères à l'écran
  • Phase 2 : Création de processus et changement de contexte entre 2 processus
  • Phase 3 : Création dynamique de processus, filiation entre processus et terminaison de processus
  • Phase 4 : Communication entre processus et attente
  • Phase 5 : Séparation de l'espace mémoire entre noyau et utilisateur; séparation du mode utilisateur
  • Phase 6 : Gestion du clavier
  • Phase 7 : Gestion du shell


III Planning

Diagramme de Gantt prévisionnel, cliquez pour agrandir
Diagramme de Gantt réalisé, cliquez pour agrandir


IV Réalisation

Phases 1 et 2

Ces deux phases, identiques au cours de Pratique du Système, nous ont permis de (re)prendre en main les outils de développement tels que l'émulateur Quemu, et GDB. Elles ont été assez rapides à implémenter, et ont permis aux membres de l'équipe n'ayant pas eu de cours de Pratique du Système de découvrir le fonctionnement de certains concepts clés (tels que les interruptions).

Phase 3

Cette phase est plus délicate à implémenter. Il est important de bien la tester : les phases suivantes sont basées sur celle-ci, et beaucoup de fonctions sont à implémenter. Il est nécessaire de bien lire les spécifications (qui sont très précises pour cette phase) pour faire les bons choix de structures de données. Coder à deux, voir à trois sur un même ordinateur (extreme programming) peut être une bonne idée et n'est pas une perte de temps.

Phase 4

Cette phase est dans la lignée de la précédente. Il est important de réaliser un ou plusieurs tests complets, et de les débugger pas à pas. C'est ce que nous avons fait grâce au test "queue" de la phase 4, qui teste 23 opérations sur une file de messages partagées entre trois processus.

Phase 5

Cette phase nous a posé quelques problèmes. Il s'agit de la phase centrale et la plus complexe du projet, et, malgré les deux jours que nous avons passé à lire la documentation sans écrire une seule ligne de code, notre compréhension de cette phase est restée incomplète pendant plusieurs jours, les encadrants corrigeant notre vision erronée en nous remettant sur la voie plusieurs fois. Il est nécessaire d'implémenter cette phase petit à petit et de bien vérifier que chaque sous-étape fonctionne afin de ne pas se retrouver avec un sac de nœuds final. En pratique cela reste assez difficile à réaliser. De plus, le débuggage se fait nécessairement en assembleur à partir du passage en mode user, ce qui complique relativement les choses. Nous avons en revanche appris énormément quant au fonctionnement de gdb lors de cette phase, et nous conseillons fortement aux étudiants des années suivantes d'en utiliser (entre autres) les commandes layout et set disassemble-next-line. La commande watch peut également se révéler très utile, ainsi que certains flags des instructions print, display et x (/x = hexadécimal, /i = instruction, /10w = 10 words...)

Au final, le mode user n'a fonctionné que le matin du rendu, ce qui a fortement limité notre capacité à corriger les bugs dans les tests réalisés par autotest (9 tests sur 23 fonctionnent entièrement, et plusieurs fonctionnent de manière partielle). Nous avons localisé un bug dans la gestion des pages partagées étant responsable de la plupart des tests échoués; nous n'avons malheureusement pas eu le temps de le localiser et de le résoudre.

Nous nous sommes référés à cette page-ci, dont nous remercions les auteurs, en complément de la documentation éparse de l'Ensiwiki.

Phase 6

Cette étape ne présente pas de difficulté majeure. Elle est divisée en deux étapes. La première vise à traiter les interruptions du clavier, en remplissant et vidant le buffer correspondant. La seconde étape est la gestion des processus en attente d'entrées / sorties du clavier. Il nous a été nécessaire de briser la conduite linéaire du projet à cette étape, en laissant une personne sur les phases 6 et 7 tandis que les deux autres continuaient le débuggage à rallonge de la phase 5.


Phase 7

Cette étape est très rapide à écrire et permet de vérifier la validité du système créé. Elle présente un test interactif et complet des différentes phases.


Bilan

Le Projet Système présente une mise en pratique efficace de nos connaissances en systèmes d'exploitation, accumulée depuis le début de notre formation.

Difficultés rencontrées

La principale difficulté que nous avons rencontré avec ce projet est le déboggage, en particulier durant la phase 5. En effet, une partie non négligeable du déboggage a lieu dans du code assembleur. Cela nous a permis de progresser dans l'utilisation de GDB. D'autre part, nous pensons la phase 5 complexe. Bien assimiler le fonctionnement de la pagination et comprendre la mémoire virtuelle est essentiel pour être efficace dans son implémentation.