Projet système PC : 2019 - JULIEN Tristan, LANUSSE Quentin : Différence entre versions

Version du 25 juin 2019 à 14:36

Titre du projet	BambinOSS
Cadre	Projet système
Équipe	Quentin LANUSSE, Tristan JULIEN
Encadrants	Gregory Mounie, Patrick Reignier, Yves Denneulin

Présentation

L'objectif du projet système est la réalisation d'un noyau de système d'exploitation sur une architecture Intel x86 et, pour la première fois en 2019, le risc-v 64 bits. Les concepts principaux à mettre en oeuvre sont :

• la création et l'exécution des processus ;
• leur synchronisation ;
• leur ordonnancement ;
• la gestion des entrées/sorties (clavier, écran) ;
• l'implémentation d'un interprète de commandes.

Equipe

• Tristan Julien (filière apprentissage)
• Quentin Lanusse (filière apprentissage)

Gestion de projet

Organisation

Nous avons décidé de faire l'intégralité du projet en pair programming afin que chacun de nous puisse bien comprendre tout ce que nous avons fait. Avec le recul, si cela nous a peut-être légèrement ralenti nous ne pensons pas que nous aurions pu aller beaucoup plus loin même avec une répartition des tâches. Nous avons également pris grand soin d'équilibrer le temps de codage et le nombre de commits de chacun, grâce à cela, nous avons tous les deux une excellent compréhension de chaque fonctionnalité notre OS.

Planning prévisionnel

Planning effectif

Phases de développement

Phase 1 : prise en main de l'environnement

Phase de prise en main du projet et de reprise des codes créés en assembleur l'an dernier.

Phase 2 : Création et lancement de processus de niveau noyau

Phase importante qui correspond au vrai début du projet, les principaux points sont :

• La création d'une première structure de processus.
• La récupération et la gestion du timer de Logiciel de base afin de traiter les interruptions d'horloge (#32).
• Le changement de contexte pour passer d'un processus à l'autre.

Phase 3 : Ordonnancement, création dynamique et terminaison de processus de niveau noyau

L'implémentation de la phase 3 a été plutôt rapide mais il a ensuite fallu débugguer les tests de cas difficiles, c'est ce qui nous a pris le plus longtemps, à la fin de cette phase les 9 premiers tests (à l'exception du 7) doivent passer. On détaille un peu plus bas comment faire les tests côté kernel.

Pour la gestion de l'endormissement, nous avons fait le choix de faire une queue de processus endormis, ce qui peut dans certains cas casser le côté FIFO de notre ordonnancement. Cela nous permet cependant d'avoir un code qui nous paraît plus clair et seulement des processus réellement activables dans notre queue de processus activables.

Pour passer le test 8 (test de performance), il nous a fallu bien vider les espaces mémoire alloués le plus tôt possible (dans kill, waitpid et exit) et ne faire une queue de processus morts à nettoyer que dans le cas particulier du exit. Cependant c'est peut-être lié uniquement à notre implémentation.

Phase 4 : Gestion des communications et synchronisation de processus de niveau noyau

Durant cette phase il faut faire attention à la documentation des primitives à implémenter, certains cas ne sont pas toujours simples à comprendre.

Nous avons choisi d'implémenter les files de messages comme des listes doublement chaînées ce qui nous semblait être le plus naturel à écrire. Nous avons également ajouté deux queues, une pour les processus en attente d'écriture et l'autre pour ceux en attente de lecture.

Attention wait_clock prend le nombre de clocks d'horloge à avoir atteint, pas le nombre à attendre... Si votre test 7 prend plus de 7-8s c'est pas normal.

Phase 5 : Séparation des espaces mémoire noyau et utilisateur : gestion de processus utilisateur

Courage... S'il vous reste moins de 2 jours c'est pas vraiment la peine de commencer sauf si vous êtes forts en espionnage industriel. Très flou, difficile de savoir par où commencer et comment déboguer, à priori une fois que on lance le mode user et à faire une première primitive ça se déroule assez simplement. Nous n'en sommes malheureusement pas rendus là.

Phase 6 : Gestion du clavier et implémentation d'un pilote de console

Phase 7 : Implémentation d'un interprète de commandes

Journal de bord

Semaine 1

05 Juin 2019

• Clonage du projet
• Prise en main de l'environnement
• Intégration dans le projet du code de gestion d'affichage développé en Logiciel de Base en 1ère Année
• Début de création d'une structure de processus

06 Juin 2019

• Modification de la structure de processus
• Début de lancement d'une fonction
• Blocages sur la gestion des piles au sein des processus
• Mise en place du context_switch()
• Découverte de l'environnement de debug

07 Juin 2019

• Fonctionnement du context_switch() avec une table des processus statique
• Début d'utilisation d'une queue des processus
• Création du logo de BambinOS

Semaine 2

11 Juin 2019

• Modification et finalisation (pour la phase 2) de l'utilisation des processus avec une queue (queue de processus activables + pointeur vers le processus actif)
• Gestion du timer
• Gestion des interruptions pour changer de processus

→ Fin de la Phase 2

12 Juin 2019

• Gestion automatique des PIDs des processus
• Gestion de l'endormissement d'un processus pour une durée déterminée : wait_clock (Phase 4)

13 Juin 2019

• Fonctions de terminaison des processus : exit, kill
• Primitives de gestion des processus : getprio, chprio, getpid
• Gestion de la filiation entre processus, et implémentation de waitpid

→ Fin de la Phase 3

14 Juin 2019

• Correction de code pour passage des premiers tests côté Kernel

→ Les tests 1 à 6 sont passés

Semaine 3

17 Juin 2019

• Correction de code pour passage de nouveaux tests
• Refacto du code pour passage du test 8 (début)

18 Juin 2019

• Fin de refacto du code pour passage du test Kernel 8
• Utilisation d'une fonction unique changer_etat() lors d'un changement d'état de processus.

• Implémentation de la base des files de messages, il faut maintenant finaliser leur mise en place pour passer les tests qui les concernent.

→ Les 10 premiers tests côté Kernel sont validés.

19 Juin 2019

• Correction de l'implémentation des files de messages pour passage de tests

→ Les tests 10 à 14 côté Kernel sont validés.

20 Juin 2019

• Mise en place de la libération d'espace alloué :
  • à des processus morts
  • à des files de messages supprimées
• Correction de code pour passage des derniers tests Kernel (15 à 20)

→ Tous les tests côté Kernel sont à présent validés.

21 Juin 2019

• Début de la phase 5 :
  • Lecture de documentation
  • Tentative de passage au mode user (ajout d'une pile user aux processus)

→ Difficile

Semaine 4

24 Juin 2019

• Phase 5...
  • Passage des fonctions à lancer côté user et corrections d'autres erreurs de ce genre.

→ Difficile d'avancer sans visibilité, on ne sait pas directement si ce qu'on fait fonctionne ou non.

25 Juin 2019

• Finalisation du projet :
  • Ajout de documentation de projet
  • Nettoyage et commentaires de code
• Quelques avancées sur la mise en place d'un mode User :

→ l'OS entre bien en mode User, mais les appels systèmes utilisés ne sont pas tous implémentés par manque de temps.

Il nous aurait donc fallu plus de temps pour avancer en debug et développer toutes les primitives nécessaires côté user.

Démonstration

Difficultés rencontrées

Les tests Kernel

Et non il ne suffit pas de copier-coller test.c dans kernel/ pour que les tests soient exécutables. Il faut récupérer la fin de user/crt0 (les UNIMPLEMENTED) et les mettre à la fin de kernel/crt0 (sauf console_putbytes). Il faut également ajouter la primitive cons_write côté kernel si vous voulez l'affichage des printf des tests (elle se contente de faire un appel à console_putbytes).