Projet système PC : 2010 - Simon GIRAUDOT et Etienne MARIN-MATHOLAZ

De Ensiwiki
Aller à : navigation, rechercher
Écran d'accueil de OS-117

L'équipe

Cette équipe a travaillé sous la tutelle de M. Franck Rousseau et se compose de deux étudiants SLE issus de Phelma :

  • Simon Giraudot
  • Étienne Marin-Matholaz


Présentation

Introduction

Ce projet consiste à créer un noyau de système d'exploitation (que l'on abrégera par la suite OS pour operating system) : il s'agit du logiciel qui fournit à un utilisateur des outils pour manipuler l'ordinateur. Sur une machine classique, ce sont par exemple les célèbres Windows, Mac OS X ou encore GNU/Linux qui remplissent ce rôle. Notre projet est bien entendu plus modeste, mais permettra tout de même de faire fonctionner une « 'machine nue' » (c'est-à-dire sans aucun autre logiciel installé dessus) en fournissant une interface simple en mode texte à l'utilisateur (on désigne par « mode texte » une interface gérée par des commandes envoyées au clavier, par opposition aux interfaces graphiques classiques qui se gèrent à la souris). L'utilisateur pourra, sur cette machine nue, et par l'intermédiaire de l'interface, lancer divers processus (à peu près équivalents à des programmes sur les systèmes d'exploitation connus).

Tout l'enjeu d'un système d'exploitation, et donc en particulier du notre, est de partager dans le temps les ressources de calcul du processeur entre les différents processus lancés par l'utilisateur, afin que ce dernier aie l'impression que tous les processus s'exécutent de manière simultanée. En réalité, un seul processeur ne peut réaliser qu'une opération à la fois, et ne peut donc traiter qu'un processus à la fois. Le processeur de notre machine nue va donc simuler la simultanéité en exécutant chaque processus tour à tour pendant des intervalles de temps très courts. Cette simultanéité est omniprésente lors de l'utilisation courante d'un ordinateur : il est par exemple banal de naviguer sur internet tout en ayant gardé ouvert un lecteur de musique.

Nous pouvons facilement diviser notre projet en deux parties :

  • La partie kernel : du point de vue utilisateur, il s'agit d'une partie totalement cachée et autonome. C'est pourtant la plus importante, puisqu'elle va gérer l'ensemble des mécanismes internes de l'OS, en réalisant des accès très contrôlés sur les parties matérielles de l'ordinateur (clavier, écran, et bien sûr le microprocesseur qui est l'élément central de l'ordinateur). Il est donc très important que l'utilisateur ne puisse interagir avec cette partie de façon très limitée et contrôlée, par le biais de ce que nous appelons des 'appels systèmes (syscalls).
  • La partie user : ce sera le mode de fonctionnement par défaut de l'OS. Elle fournira une interface à l'utilisateur, le shell (une invite de commande qui pourra lancer des processus sur demande de l'utilisateur).

L'OS-117

Un OS simple à utiliser

Nous avons appelé notre système d'exploitation OS-117 (en hommage à un célèbre espion dont la réputation n'est plus à refaire). Il s'agira d'un OS relativement léger et simple, orienté vers l'observation et la fiabilité. Le but principal, en plus de proposer un OS stable, est de fournir à l'utilisateur des outils pratiques et simples d'utilisation pour observer le fonctionnement interne de son système en toute sécurité.

Fonctionnalités

Robustesse

Dans le cadre du Projet Système, un jeu de test relativement complet et pointilleux nous a été fourni : il nous a permis de mettre à l'épreuve la robustesse de notre OS et à corriger les points qui s'avéraient défectueux pendant les tests.

Utilisation du jeu de tests

Suite à la série de débogages que nous avons effectués, nous avons réussi à couvrir avec succès 90% des tests (soit 18 des 20 tests fournis). Nous reviendrons sur les tests échoués ultérieurement. Dans un soucis de transparence, nous donnons la possibilité à l'utilisateur de lancer lui-même ces tests (après avoir lancé la commande basedetests dans le shell fourni). Ci-contre, un exemple d'exécution des tests avec affichage de leurs résultats.

Observation du système en temps-réel

Par défaut, il est possible de lancer des commandes permettant d'avoir des informations sur le système (ps pour afficher tous les processus lancés, et pinfo pour afficher les files de messages présentes dans le système) : on se rendra vite compte que ces commandes n'ont que peu d'intérêt si on les lance simplement dans le shell. Le plus intéressant serait de les lancer pendant l'exécution d'autres processus, mais c'est impossible puisque pendant l'exécution d'autres processus, nous ne pouvons envoyer de commande au shell (de plus, comme la plupart des processus écrivent des choses à l'écran, ce serait assez compliqué d'écrire des commandes en même temps).

Observation du système en temps-réel

Notre solution consiste à fournir deux commandes rapides pour permettre à l'utilisateur de lancer ces processus d'observation instantanément, et à n'importe quel moment :

  • La touche F1 permet de lancer ps
  • La touche F2 permet de lancer pinfo

Pour des raisons de commodité, nous avons également associé la touche F3 à l'horloge : si l'horloge est affichée (en haut à droite), F3 l'efface, et si elle est effacé, F3 la réactive.

Historique des commandes

Certaines commandes peuvent être longues, et le shell n'accepte ni erreur ni auto-complétion : pour pallier à ces manques, nous avons implémenté un système d'historiques des commandes tapées. Dès lors que l'utilisateur valide une commande (avec la touche Entrée), celle-ci est sauvegardée dans un historique auquel il sera par la suite très simple d'accéder : les touches de direction haut et bas permettent de naviguer très intuitivement dans l'historique des commandes.

Cet historique permet, avec la version de l'OS fournie, de stocker 100 commandes, mais ce nombre est extensible en modifiant une simple valeur dans le code source.

Difficultés rencontrées

Les deux tests qui échouent

Comme nous l'avons déjà évoqué, dans le jeu de tests fournis, notre OS échoue sur deux d'entre eux. Il s'agit des tests 9 et 18 :

  • Le test 9 vérifie que la sauvegarde des registres du processeur (de petits espaces de stockage qui servent à effectuer les calculs très bas niveau du processeur) est correctement effectuée lors du passage du mode user (protégé) au mode kernel (superviseur). Nous n'avons, à ce jour, pas réussi à déterminer quels registres en particuliers nous avions oublié de sauvegarder. Notons toutefois que, ce test mis à part, aucun des tests effectués et des processus que nous avons lancés ne dysfonctionnent, il nous a donc paru plus judicieux de nous concentrer sur la suite du projet, plutôt que de faire fonctionner ce test.
  • Le test 18 a montré qu'il était possible, en tant qu'utilisateur, d'accéder directement à toutes les fonctionnalités du kernel, alors que les accès au noyau sont normalement contrôlés à l'aide des appels systèmes. Nous ne sommes cependant pas parvenus à trouver l'origine de ce piratage, le code utilisé étant relativement complexe, nous n'avons pu trouver la faille exploitée.

Passage kernel/user

Nous avons passé beaucoup de temps à comprendre les enjeux du passage entre les modes kernel et user, ce qui nous a donc retardé dans notre planning prévisionnel. Ce n'est que le dernier jour que nous nous sommes rendus compte que, si notre fonction de passage vers le mode user fonctionnait correctement, la création d'un processus faisait par contre repasser l'OS en mode kernel de façon irrémédiable. Nous avons finalement pu corriger cela en adaptant la fonction de création de processus en forçant le passage en mode user après chaque création de processus.

Bilan

Dernier exemple : création d'une longue lignée de fils

D'un point de vue technique, ce projet nous a permis de mettre en application un grand nombre des notions acquises tout au long de l'année, de mieux percevoir l'architecture d'un système d'exploitation et de comprendre les principales problématiques résultant de sa conception.

D'un point de vue organisationnel, nous avons appris à partager des tâches qui pouvaient parfois se révéler très dépendantes : cela nécessitait donc une bonne entente préalable quant à la conduite du projet. Même si nous n'avons pas pu respecter le planning prévisionnel, OS-117 est fonctionnel et est capable de mener à bien les fonctionnalités fondamentales d'un système d'exploitation classique.