Projet système PC : 2017 - Dimitri Abbey, Yvan Bourrut, Nicolas Violette

De Ensiwiki
Aller à : navigation, rechercher
Loading screen Mockup.png
Titre du projet frOSen
Cadre Ensimag

Équipe Dimitri Abbey Yvan Bourrut Nicolas Violette
Encadrants François Broquedis , Gregory Mounié, Patrick Reignier


Journal de bord

Liste chronologique des jours, puis sous-liste chronologique des tâches

Jeudi 08 juin 2017

  • Présentation initiale du projet par M.Broquedis
  • Nico et Yvan : Mise en place du Makefile amélioré pour lancement Qemu, et GDB. Liaison avec NetBeans, partage de la config avec d’autres groupes ❤️‍
  • Dimitri : Mise en place du code nécessaire à l’affichage à partir du code réalisé en TP de Logiciel de base.
  • Café
  • Fin phase 1 !
  • Travail commun (triplet programming) sur la modélisation d’un processus puis sur le changement de contexte
  • Fin : Changement de contexte a donné un résultat qui semble ok

Vendredi 09 juin 2017

  • Début : Reprise du travail commun pour arriver à garder les arguments lors du changement de contexte
  • Yvan et Dimitri : Mise en place des arguments, gestion du temps, et début de Scheduler
  • Nico : Mise en place de l’archi pour les tests automatiques
  • Prise d’avance sur la phase 3 avec le sleep et la phase 4 avec le wait (on est trop fort ! ❤️‍)
  • Changement des tailles de piles statiques en dynamique (welcom to hell)
  • Week-end !

Lundi 12 juin 2017

  • Début : Questionnement sur l’intérêt de continuer le travail sur les piles dynamiques
  • Fin phase 2 !! ❤️‍
  • Brainstorming sur la façon d’implémenter l’ordonnanceur
  • Travail commun pour mettre en place une liste chainée des processus, triée par priorité
  • Yvan : Validation des algos par ré-écriture en Java,
  • Dimitri : Scheduler
  • Nico : Fonctions systèmes pour la gestion des processus

Mardi 13 juin 2017

  • Début : Répartition des tests sur la gestion des processus
  • Nico, Yvan : Tests
  • Dimitri : Fignolage et correctifs
  • Yvan, Dimitri : Modif de la façon de gérer la pile
  • Fin phase 3 !!! ❤️‍ ❤️‍
  • Nico, Yvan : Mise en place des files de messages
  • Dimitri : Travail que la gestion de la mémoire (retour à une allocation statique car bug supposé du mem_alloc)
  • Yvan : Tests des messages
  • Nico : Changement de l’archi des tests pour mieux organiser les fichiers
  • Dimitri : Travail sur mem_alloc (en fait dynamique ça va)
  • Activité support commune pour aider 3 autres groupes ❤️‍

Mercredi 14 juin 2017

  • Tests et beaucoup de débogage sur les messages
  • Dimiri : Gestion de la mort d’un processus père et de la mort des enfants d’idle
  • Nico, Yvan : Tests sur les messages
  • Débuguage commun du pcount (et donc de precieve + psend) qui n’affiche pas les bonnes valeurs

Jeudi 15 juin 2017

  • Adaptation des tests fournis dans user à notre architecture (tests 1-13)
  • Correction des 50000 bugs que cela a révélé
  • Lecture préparatoire du sujet de la phase 5

Vendredi 16 juin 2017

  • Fin de l’adaptation des tests profs (tests 14-17 + 20)
  • Passage du tableau de stockage des messages d’une taille statique à dynamique
  • Recherche de nom pour le projet : frOSen ❤️‍
  • Réflexion sur la manière de passer initialement en userspace

Lundi 19 juin 2017

  • Suites des réflexions/recherches sur l’userspace
  • Fin phase 4 !!!! ❤️‍ ❤️‍ ❤️‍
  • Travail commun pour essayer de faire marcher un premier appel système
  • Travail sur le passage du mode superviseur au mode utilisateur
  • Choix de commencer par l’écriture d’un syscall en fait
  • Ecriture de console_putbytes -> ok =D
  • Dimitri : Passage userspace
  • Yvan : Écriture syscalls
  • Nico : Adaptation makefile pour mode user

Mardi 20 juin 2017

  • Fin du travail sur phase 5 ❤️‍
  • Changement de l’architecture des tests pour la faire marcher en userspace à partir de la phase 5 (-_-)
  • Débogage du test prof 4 qui ne marche étonnamment plus après le passage dans l’userspace

Mercredi 21 juin 2017

  • Suite débogage test 4
  • Fin phase 5 !!!!! ❤️‍ ❤️‍ ❤️‍ ❤️‍
  • Insertion du logo dans le début de l’userspace
  • Gestion des entrées clavier
  • Passage du test 18
  • Recherche infructueuse sur gestion du speaker interne

Jeudi 22 juin 2017

  • Correctifs Phase 6
  • Fin Phase 6 !!!!!! ❤️‍ ❤️‍ ❤️‍ ❤️‍ ❤️‍
  • Interpréteur de commande
  • Commandes ps, sleep, su, logo, echo, shutdown, time, waitall …
  • Fin Phase 7 !!!!!!! ❤️‍ ❤️‍ ❤️‍ ❤️‍ ❤️‍ ❤️‍
  • Fonctions de debug supplémentaires
  • Recherches sur la possibilité de support du multi-processeur

Vendredi 23 juin 2017

  • Décision d'abandonner le multi-processeur, c'est trop galère
  • Travail sur la gestion Sound Blaster
  • Lecture doc Sound Blaster
  • Recherche sur Sound Blaster
  • Essais non-concluants pour Sound Blaster...

Lundi 26 juin 2017

  • Suite prise de tête sur Sound Blaster...
  • Découvert d'un bug étrange à la fin du test 20 en userspace
  • Tentative de résolution dudit bug

Mardi 27 juin 2017

  • Correction du bug précédemment mentionné
  • Finalisation Sound Blaster... -> Ça ne marche pas. ='(
  • Bataille pour essayer de faire marcher VirtualBox sur les machines de l'Ensimag afin de mieux débuguer Sound Blaster. Finalement, la moitié des commandes nécessaire pour importer le kernel.bin d'après l'ensiwiki nous sont interdites (impossible également de faire une clé bootable) ou ne marchent juste pas (logiciels pas à jour)
  • Remise au propre du wiki
  • Préparation démo

Mercredi 28 juin 2017

  • Démo finale =D

Avancement du projet

Phase 1

100 %

La phase 1 a principalement consisté à récupérer le code réalisé en cours de Logiciel de base pour pouvoir réaliser des affichages (printf). Nous avons également défini notre environnement et nos outils de travail.

Lors de cette phase, nous avons modifié le Makefile afin de pouvoir lancer le projet plus simplement.

Phase 2

100 %

Nous avons tout d'abord mis en place la structure de processus en nous basant partiellement sur le prototype de la fonction start pour déterminer les attributs nécessaires. Pour stocker les processus du système, nous avons fait le choix d'utiliser un tableau statique étant donné que le nombre de processus sur le système est limité. Nous aurions pu utiliser une liste chaînée mais pour minimiser le nombre d'allocation dynamique, le tableau statique s'est présenté comme un choix raisonnable.

Par la suite, nous avons cherché à mettre en place le context switch. Nous avons d'abord réfléchi sur l'implémentation de celui-ci avant de nous être rappelé qu'il était fourni sur ensiwiki. Malgré cela, nos idées correspondaient à ce qui est fourni mais étaient incomplètes.

En fin de phase 2, nous avons mis en place, parallèlement, une architecture de tests automatiques et la gestion du temps. Pour la gestion du temps, nous avons repris la gestion de l'horloge vu en cours de Logiciel de base et mis en place un ordonnanceur simpliste (switch entre 2 processus) appelé lors de l'interruption d'horloge. Nous avions également pris un peu d'avance en développant en partie les fonctions d'endormissement et de réveil de processus. Nous avons également également revu notre implémentation des processus pour remplacer la pile, allouée statiquement au début de la phase (tableau défini directement dans la structure) par une pile allouée dynamiquement.

Phase 3

100 %

La phase 3 consiste à implémenter l'ordonnanceur ainsi que la gestion du cycle de vie des processus.

Nous avons réfléchi ensemble pour trouver le moyen le plus efficace possible (en terme de temps de calculs) pour implémenter l’ordonnanceur. Nous avons décidé de mettre en place une liste chainée des processus, triée par priorité puis par ordre de création. Nous avons plus tard revu sur cette architecture de manière à avoir une telle liste pour chaque état de processus, afin de faciliter les différents traitements et afin d'améliorer leur temps d’exécution.

Une fois ceci fait, l'implémentation des différentes fonctions des spécifications pour la gestion des cycles de vie a été assez simple.

Phase 4

100 %

La phase 4 demande de mettre en place un système de file de messages. Nous avons implémenté ceci de manière très classique, avec un tableau de tableaux, chacun de ces derniers contenant des structures représentant un message. Nous utilisons un index de lecture et un index d'écriture cycliques pour gérer l'aspect FIFO. Nous avons aussi ajouté des compteurs de processus bloqués en lecture ou en écriture.

Cette phase nous a posé quelques problèmes de conception :

  • Une mauvaise compréhension de la spec concernant la gestion des processus bloqués
  • Un problème de synchronisation entre le réveil d'un processus et la non-garantie qu'il arrivera le premier pour lire/écrire son message

Phase 5

100 %

La phase 5 a été la première grande difficulté du projet. Nous avons tout d'abord réfléchi à comment passer en mode utilisateur. Ne trouvant pas, nous avons donc tout d'abord implémenté les appels systèmes. Ceci n'a pas été très dur à mettre en place mais nous avons dû modifier l'implémentation une fois le mode utilisateur mis en place. Lorsque nous avions vu les interruptions en cours de Logiciel de base, la notion de niveau de privilège n'avait pas été mise en avant et nous n'avions donc pas pris en compte que le code que nous utilisions pour initialiser la table d'interruptions était valide uniquement pour le mode superviseur.

Pour le passage au mode utilisateur, nous avons donc cherché des références sur Internet. Le site OSDev.org nous alors introduit les notions de niveaux de privilèges (Ring 0 à ring 3) pour un processeur x86 ainsi qu'une implémentation possible de la fonction permettant de passer au mode utilisateur. Ainsi, il faut faire croire au processeur que l'on répond à une exception/interruption pour pouvoir le faire passer en mode utilisateur.

L'ajout d'un pile "espace utilisateur" n'a pas été un grand problème, le code d'allocation étant fourni et ayant déjà pris en compte dès l'implémentation du démarrage d'un processus que la pile utilisateur nécessite d'une extension de taille minimale pour pouvoir y stocker des éléments nécessaires (argument, adresse de la fonction de fin de processus, ...).

Nous avons également dû adapter nos tests au mode utilisateur.

Phase 6

100 %

La phase 6 consiste à implémenter une console avec une lecture du clavier. Pour récupérer les entrées clavier, nous avons récupéré et adapté le travail déjà réalisé en TPs de logiciels de base. Cela nous a notamment demandé de traduire les scancodes en lettre, et d'implémenter un stockage dans un buffer.

Phase 7

100 %

L'interpréteur de commande que nous avons implémenté fonctionne de manière assez similaire à celui de l'ensishell réalisé en TP de système. Nous avons mit en place une structure qui sera remplie avec la ligne saisie par l'utilisateur (système de argc et argv). Les & servant à lancer les commandes en arrière-plan ne sont pas traités comme un argument supplémentaire.

Une fois l'interpréteur fonctionnel, nous avons fait les quelques commandes suivantes (non sans quelques easter-eggs, bien évidemment) :

  • ps : affiche la liste des processus
  • shutdown : "éteint" le système
  • logo : ré-affiche le logo de démarrage du système ❤️‍
  • su <NOM> : change le nom affiché dans le prompt
  • echo [on|off] : active ou non le retour des saisies clavier
  • sleep
  • time <COMMAND> : calcul le temps d'éxecution d'une commande
  • waitall : attent que tous les enfants du processus soient zombifiés, puis les tue
  • run_test : lance les jeux de tests (les notre + ceux fournis de base)

Extensions

Multi-processeur

1 %

L'extension consistait à gérer les multiples processeurs. L'extension à été choisie car nous l'avions vue dans le sujet et elle nous paraissait intéressante. Cependant, après une rapide lecture des documentations ainsi qu'après un retour des encadrants, nous avons décidé d'abandonner l'idée face à la complexité de la chose.

Sound Blaster

70 %

Nous avons voulu implémenter la gestion de la carte son pour pouvoir jouer "Libérée, délivrée" pendant la démo. Cependant, nous n'avons pas pu finir le développement de celle-ci. Malgré le grand nombre de sources mises à disposition, certaines notions nous manquaient et cela a grandement affecté notre rythme de développement. De plus, toutes les sources trouvées prenaient en compte que le lecteur connaisse déjà certains détails techniques (gestion du contrôleur DMA (Direct Memory Access) par exemple). Dernière difficulté, qemu freezait lorsque l'on commencait à transférer des données à la carte son et que les interruptions étaient démasquées et le protocole fourni pour utiliser VirtualBox ne fonctionnait pas.

A défaut d'avoir un semblant de musique, nous avons néanmoins un "Bop" sonor indiquant que la carte SoundBlaster est bien sous tension et reconnue par l'OS, c'est déjà pas mal =)

Source

OSDev.org : Une excellente source d'information pour le développement de systèmes d'exploitation

StackOverflow : Une bonne source pour la résolution de certains bugs ou la recherche d'information

Software Developer's Manual d'Intel : La documentation Intel qui, bien que très dense, fournit un bon nombre d'informations utiles (essentielles pour le multiprocesseur par exemple)

Sound Blaster 16

Sound Blaster Series Hardware Programming Guide : Documentation officielle pour les anciennes cartes son Sound Blaster (Sound Blaster 16 comprise)

PrograZine Programmation de la Sound Blaster : Source supplémentaire pour la Sound Blaster 16

Sound Blaster 16 Programming Document : Source supplémentaire pour la Sound Blaster 16

Projet système de Maxime HAGENBOURGER,IJ et Rémi SAUREL : Source des sources pour la programmation de Sound Blaster 16