Projet système PC : 2021 - Hugo COLINET, Gatien DUCORNAUD, Mathis MARION, David NADJAR

De Ensiwiki
Révision de 7 mai 2021 à 21:53 par Ducornag (discussion | contributions)

(diff) ← Version précédente | Voir la version courante (diff) | Version suivante → (diff)
Aller à : navigation, rechercher
Asciiart.png
Titre du projet Projet Conception Système d'Exploitation (Approfondissement): PablOS Cobar
Cadre Projets de spécialité

Équipe Hugo COLINET, Gatien DUCORNAUD, Mathis MARION, David NADJAR
Encadrants Mathieu BARBE


BIENVENUE SUR LA PAGE ENSIWIKI DE PablOS Cobar


Objectif

Le but de ce projet de d'approfondir les problématiques vues en PCSEF, mais sous une architecture RISC-V, et construire un système d'exploitation à partir d'un squelette fourni.


Équipe

Nous sommes tous les 4 des étudiants de deuxième année de la filière ISI.

Hugo COLINET

Gatien DUCORNAUD

Mathis MARION

David NADJAR

Organisation

Nous avons utilisé un serveur discord personnel pour s'organiser entre nous, et le serveur discord dédié au projet comme point de contact avec le professeur. Au cours du projet nous avons fait du test-driven programming avec les tests fournis, qui ont demandé un certain nombre d'aller-retours entre différentes parties du code.

Phases du développement

Étape 0 : Prise en main de la spécification/Mise en place de l'environnement RISC-V

100 %

Cette étape a été plutôt différente pour chacun : si cela s'est révélé plutôt simple sur les machines de l'ENSIMAG grâce au patch de qemu fait par le professeur, cela s'est révélé plus complexe en passant par docker sur les machines personnelles pour certains.

Étape 1 : Mode machine

100 %

Cette partie ne nous a pas posé problème initialement mais il a fallu revenir sur les interruptions timer et le découpage en frame lors des étapes 2 et 3 du projet. Le wikipédia mis en place nous a beaucoup aidé à cette étape.

Étape 2 : Mode supervisor

100 %

La mémoire virtuelle a été un point qui a été revu tout au long du projet : entre la mémoire partagée, puis l'allocation de tas par processus, et la copie dans l'espace mémoire correcte des programmes utilisateurs. Si les bases ont été rapidement codées sans soucis, il a fallu souvent revoir certains points et détails, et a nécessité de nombreux aller-retour avec les professeurs, autant en PCSEA que en cours d'architecture avancée
Pour la gestion des processus, elle s'approchait beaucoup de ce qui avait été vu en PCSEF, mais certains points ont quand même posé problème, notamment le context switch (savoir quels registres sauver), et le premier chargement lors du lancement du processus. Pour le reste, les solutions trouvées en PCSEF ont été portées sur ce projet.
Les files de messages ont aussi été un point dont le développement s'est fait tout au long du projet. Il a fallu mettre en place un système de listes chaînées de processus en attente sur une certaine condition que l'on pourrait vider et remplir au fur et à mesure que les processus se retrouvent bloqués sur les conditions et que d'autres processus viennent les débloquer. Il a fallu gérer de nombreux cas particuliers comme par exemple les interactions avec chprio et kill, l'autocomplétion de file après un preceive sur une file pleine avec des processus en attente sur file pleine ou le don de message lors d'un psend sur une file vide avec des processus en attente sur file vide. Dans les deux premiers cas, il fallu mettre en place un système de mise à jour des listes chaînées de processus en attente. Dans les deux autres, il a fallu trouver un moyen d'échanger un message avec un processus sans lui donner la main s'il n'était pas plus prioritaire que le processus élu. Pour cela, nous avons ajouté une variable de plus à la structure représentant les processus dans lequel on pourrait stocker le message à prendre ou le message qui a été donné. Normalement, il devait y avoir un système de mutex pour permettre aux processus de passer en section critique lors d'appels aux fonctions des fils de messages mais ces derniers n'ont pas été implémentés par manque de temps. Il peut donc potentiellement y avoir un problème si l'on appelle l'ordonnanceur alors que le processus élu exécute une de ces fonctions et qu'un autre processus exécute une autre de ces fonctions avant que le premier ait fini ce qu'il faisait.

Étape 3 : Mode user

100 %

Le passage en mode user a posé de nombreuses questions et a nécessité de retravailler sur un certain nombres de problématiques des étapes antérieures (comme indiqué ci dessus) : il a fallu revoir la mémoire et la gestion des piles, de même que le chargement des processus. Les phases de tests ont aussi montré certaines failles dans la gestion des processus et du timer. L'écriture du shell a nécessité quelques modification des API system.

Le shell propose les 4 commandes suivantes :

  • help pour afficher les commandes natives du shell
  • apps pour afficher les programmes présents dans l'OS
  • ps pour afficher la liste des processus en cours d'exécution
  • exit pour éteindre la machine

Extensions

  • Du fait de la compréhension du sujet, nous avons codé dans le shell la possibilité de lancer les programmes en arrière-plan, avec l'ajout de & en fin de commande (comme pour un shell bash classique).
  • Nous avons aussi implémenté une politique d'ordonnancement différente qui est activable en définissant la macro TOURNIQUET. Cela permet de donner du temps à tous les processus, pas seulement celui de priorité le plus fort (mais bien moins de temps pour ceux de priorité le plus faible), afin d'éviter qu'un processus de priorité forte puisse bloquer complètement le système.

Journal de bord

Du 04/02/2021 au 04/03/2021 - Prise en main et portage

  • Prise en main de l'environnement de travail
  • Démarage de l'OS
  • Début gestion processus: portage du code PCSEF
  • Timer machine/traps machine

Du 04/03/2021 au 04/04/2021 - Mode superviseur

  • Découpage des frames
  • Passage en superviseur
  • Début mémoire virtuelle
  • Gestion basique des processus (naissance, retour, échange de contextes...)

Du 04/04/2021 au 07/05/2021 - Fonctionnalités complexes

  • API système et gestion avancée des processus (wait, kill...)
  • Passage au mode utilisateur
  • Portage des tests dans l'espace user
  • Clavier (UART)
  • Files de messages
  • Shell

Difficultés

La répartition de la charge de travail a été notre problème principal : du fait de notre expérience différente, de la charge de travail demandée par les autres matières (différentes entre les membres de l'équipe) et de l'environnement de travail à distance, certains membres ont porté une charge de travail plus importante. Le développement sous RISC-V est totalement nouveau pour tous et les ressource sont très denses : nous avons donc du souvent nous reposer sur les réponses à nos questions par le professeur, puis il était difficile de se plonger dans une partie différente car cela nécessitait une bonne compréhension et devoir discuter longuement avec la personne en charge de la partie, le ralentissant ainsi.