Projet système PC : 2014 - ANDRE-POYAUD Tom, MONTOVERT Théophile, RIBES Gaël

De Ensiwiki
Aller à : navigation, rechercher
Project schedule.png
Titre du projet TypOS
Cadre Projet Système d'Exploitation 2014
Page principale Projet_système

Encadrants Damien Dejean Gaëtan Morin Grégory Mounié


TypOS

Présentation générale

TypOS est un système d'exploitation implémenté avec des fonctions basiques comme la gestion de l'affichage, des processus et une séparation noyau-utilisateur. TypOS cherche à rendre son utilisation claire et intuitive. Le terminal disponible permet une interaction simple et efficace avec l'utilisateur.

Gestion de projet

Git

L'utilisation de Git pour un projet comme celui-ci a été efficace. Nous avons décidé en amont de ne pas utiliser de branches étant donné que le projet allait se dérouler plus ou moins de manière séquentielle. Ainsi, nous avons pu faire des commits propres validant toujours une exécution du système d'exploitation.

Répartition des tâches

La répartition des tâches a été difficile car nous ne disposions que de deux machines de développement (CentOS présentant des bugs et l'administration ne pouvant plus délivrer de PC portables). Nous avons cependant pu paralléliser certaines tâches comme la séparation du noyau et de l'utilisateur avec l'écriture des pilotes clavier et du shell. Aussi, une implémentation succincte des processus nous a permis de développer la filiation des processus en parallèle du développement des sémaphores.

Phases de développement

  • Phase 1 La prise en main du projet ne nous a pas posé de problème majeur. Lors de l'implémentation de la gestion de la console d'affichage et du curseur, nous avons pu prendre en main l'environnement de développement (plus précisément les ressources dont nous disposions). A l'issue de cette phase, certains bugs ont persisté. Nous nous en sommes rendu compte que plus tard, et cela nous a sensibilisé sur l'importance d'effectuer de nombreux tests même pour des fonctionnalités a première vue mineures.
  • Phase 2 En premier, nous avions choisi d'implémenter de manière dynamique les stacks des processus en les gérant avec nos propres listes à priorité. Après avoir découvert que l'implémentation des listes à priorité était donné et que le déboggage des processus allait être douloureux, nous avons changé toute notre implémentation en définissant de manière statique la liste des processus et leurs stacks kernel. Une fois les principales fonctions de gestion des processus développées, nous les avons ardemment testées pour valider le changement de contexte et le passage des paramètres.
  • Phase 3 Une fois le changement de contexte mis en place, nous avons pu démarrer le développement du cycle de vie et de l'ordonnancement des processus. A notre grand regret, nous n'avons pas pu choisir notre politique d'ordonnancement. Le développement de cette phase a été relativement rapide, de l'ordre de 1 à 2 jours. Quelques bugs ont persisté suite à une importante phase de test, mais ils ont été rapidement résolus à la phase suivante.
  • Phase 4 Le développement des sémaphores s'est fait en parallèle de la phase 3. Tout d'abord, nous avons choisi d'implémenter le lock avec l'instruction TSL qui permet de gérer simplement mais surtout efficacement l'accès aux ressources critique. Après avoir compris que cette instruction est utile uniquement lorsque plusieurs processus qui s'exécutent en même temps cherchent à accéder a une même ressource (multi-coeur), nous avons réduit ce lock à un booléen. Il sera totalement supprimé après l'implémentation du mode user, étant donné qu'à partir de là il ne peut plus y avoir d'interruptions coté kernel.
  • Phase 5 La séparation du mode noyau et du mode utilisateur a été une étape difficile du projet. L'inter-dépendance du développement de la librairie des appels systèmes, du changement de registres, du passage des paramètres ainsi que des fonctions de démarrage (user_start) et de terminaison (end_user_process) nous a obligé à tester méticuleusement une fois ces développements terminés. Néanmoins, l'ajout de l'interruption logicielle a été longue à comprendre dans les détails (lecture de la documentation intel) malgré la simplicité de son implémentation. Aussi, il nous a fallu du temps pour trouver la manière la plus propre, selon nous, d'implémenter la fonction de terminaison de processus en mode user.
  • Phase 6 Le développement de la console n'a pas été difficile en soit (ajout et gestion de l'interruption matériel). Les fortes contraintes liées au buffer nous on posés quelques petits problèmes d'implémentation qui ont été vite résolus grâce aux tests.
  • Phase 7 Nous avons développé l'interpréteur de commandes directement à la suite du pilote clavier, en parallèle du premier jour de travail sur le mode user. Notre interpréteur de commandes permet de gérer de multiples arguments grâce à une structure contenant les classiques argc et argv, passée en paramètre de toute fonction de commande, et une fonction split transformant la chaîne entrée par l'utilisateur en la structure précitée.

Conclusion

Pour finir, l'ensemble des phases a été réalisé et testé avec soin. Nous avons privilégié un développement robuste au détriment de certaines extensions que nous pensions pouvoir développer dans le temps imparti comme le driver Ethernet ou le driver audio.