Projet système PC : 2010 - Adrien Oliva et Paul Roy

De Ensiwiki
Aller à : navigation, rechercher

Mycomputer.png  Deuxième Année  CDROM.png  Informatique 

Vous trouverez ici une description du noyau du système d'exploitation pOSket, développé dans le cadre du projet de spécialité de deuxième année à l'Ensimag par Adrien Oliva et Paul Roy entre le 20 mai 2010 et le 15 juin 2010.

pOSket

About-posket.png

développeurs : Adrien Oliva, Paul Roy


Le projet

Le but du projet est de concevoir un système d'exploitation permettant d'utiliser un ordinateur classique avec des primitives basiques et essentielles. Ce système doit en plus être multi-tâche (il doit pouvoir executer plusieurs programmes en même temps !). Puisqu'une démonstration vaut mieux qu'un long discours, vous pouvez télécharger les binaires du noyau directement via le lien suivant Media:POSket-Kernel.bin.gz Afin de lancer notre noyau, je vous recommande chaudement la lecture de la page suivante qui explique comment démarrer le noyau à partir d'une clé USB via grub ou sur Virtual Box : environnement de travail

Les objectifs

Les objectifs de base de ce projet sont multiples et décrits dans le cahier des charges. Voici un résumé des attentes :

  • multi-tâche : le système doit être capable d'éxécuter plusieurs programmes «en même temps», en partageant les ressources.
  • communication entre processus en utilisant des files de messages.
  • instaurer une protection dans l'utilisation du noyau en séparant les applications éxécutées par l'utilisateur et les actions nécéssitant des privilèges de super-utilisateur comme la création ou la destruction de processus.

Au niveau extensions, nous avions prévu au début du projet de pouvoir afficher un terminal dans une résolution plus grande que celle d'origine (80x25), mais des problèmes de compréhension sur lesquels nous reviendrons plus tard et un calendrier qui avance toujours de plus en plus vite nous ont contraint à uniquement nous renseigner sur l'utilisation du driver graphique VESA.


Fonctionnement

Le fonctionnement de pOSket est assez simple. Aucune manipulation spéciale n'est nécessaire pour démarrer le noyau et ce démarrage nous ammène jusqu'à l'écran d'acceuil du sysème.

Start-pOSket.png

À ce moment, le système vous invite à taper la command help afin de prendre connaissance des différentes fonctions implantées dans le terminal et disponnibles à l'éxécution. Ces commandes sont :

  • echo <string> affiche <string> à l'écran.
  • clock affiche le nombre de ticks depuis le démarrage du système.
  • test <num> lance la batterie de test. Sans l'argument, les tests sont lancés en mode interactif, sinon, le test <num> est éxécuté.
  • reboot ou exit redémarre le système.
  • help <cmd> affiche l'aide de pOSket. Sans argument, cette commande donne la liste des commandes disponibles. En ajoutant un nom de commande en argument, help se transforme en man-page et donne plus de détail sur l'utilisation de <cmd>.
  • info liste les processus actifs courrants.
  • pinfo liste les files de message en cours d'utilisation.
  • kill <pid> tue le processus identifié par pid.
  • ps affiche les processus courant toutes les 3 secondes.
  • clear efface l'écran.
  • about affiche des information quand au développement du système à l'attention de l'utilisateur $\lambda$
  • example éxécute une série d'exemple.

Bilan

Nous allons maintenant conclure sur ce projet avec les deux rubriques suivantes.

Apport du projet

S'il est intéressant de se demander ce que nous avons apporté au projet (ce qui a été dit plus haut), il faut aussi savoir s'auto-évaluer d'un point de vue critique en se demandant ce que ce projet nous a apporté.

Ce projet système, étalé sur une période de 4 semaines, est un projet très enrichissant de part sa complexité et sa longueur. La première chose remarquable est la manière dont il faut gérer son temps. Nous avons facilement perdu du temps au début en cherchant à être "trop" autonomes, ce que nous avons corrigé par la suite. C'est un des apports du projet que nous retiendrons le plus, car celui-ci nous a particulièrement gêné pendant la première moitié du projet. Ceci nous montre que tout projet un peu long ne peut être pris à la légère.

Un second point remarquable reste aussi la connaissance en terme de systèmes. En effet, les différents points abordés (processus / files de messages / mode kernel / ...) sont des outils puissants et très utiles dans le monde informatique. Outre ces connaissances pures, ceci nous donne une vision plus générale de ce qu'est un "Système d'exploitation", et la manière dont celui-ci fonctionne. Cet aperçu plus global nous permet de bien réaliser la complexité, par exemple, de deux processus qui se passent la main.

Un dernier point important est tout simplement la cohésion d'une équipe. Notre équipe est formé de deux binômes qui se connaissaient et qui s'apprécient, et nous avons pu réaliser la portée de cette cohésion. En effet, grâce à cette formation d'équipe, nous comprenions facilement ce que l'autre voulait en cas de problèmes, sa manière de penser, ses apports, ce qui nous a permis de gagner un temps précieux et de rattraper notre retard à la moitié du projet. On comprend aisément qu'une mauvaise formation d'équipe, ou une équipe peut souder peut considérablement freiner la bonne conduite d'un projet.

Difficultés rencontrées

La première difficulté que nous avons dû surmonter est le changement de contexte des processus (lorsqu'on "passe la main" en quelque sorte). Ceci se passe à bas niveau, et nécessite une compréhension parfaite de la gestion des piles et de la sauvegarde de registres, car la moindre erreur peut passer inaperçue mais considérablement gêner le fonctionnement du système.

Le second point qui nous a posé problème est la protection utilisateur du noyau (c'est à dire empêcher l'utilisateur d'exécuter des commandes privilégiées, réservées au noyau). Encore une fois, cela nécessite une gestion parfaite des piles, et une rigueur sans égal. C'est une des parties qui nous a pris le plus de temps pour arriver à notre résultat final. Ce qui nous manquait pour y arriver rapidement était une "image générale" du fonctionnement d'un système, ce que nous avons acquis au fur et à mesure.

Les spécifications ont aussi été un de nos gros problèmes. La plupart du temps, les spécifications étaient précises, mais parfois difficiles à appréhender et à comprendre (et parfois mal lues). Cela nous a beaucoup retardé (lors files de messages par exemple) et nous a été chronophage lors du debug de la batterie de tests fournie. C'est sur ce point que nous avons voulu rester trop autonomes, là où demander beaucoup d'informations aux encadrants aurait été un gain de temps précieux (nous aurions surement pu aller jusqu'aux extensions). Cela nous amène au dernier point :

Le temps. C'est ce qui nous a le plus posé problème : nous avons perdu énormément de temps autour de points qui auraient dû être réglés rapidement, et on se rend compte de la difficulté de la gestion de temps. Si ce projet était à refaire, nous changerions fondamentalement la gestion de ce paramètre. Bien que nous ayons été prévenus de la longueur du projet, le retard s'est fait ressentir sur la fin, car nous avons sous-estimé certaines parties (notamment debug).

Outils utilisés

Les différents outils que nous avons utilisé sont :

  • le dépôt SVN, pour la gestion de version
  • une machine virtuelle (VirtualBox), pour les tests
  • des éditeurs de texte (vim et gedit)
  • planner (pour la gestion des Gantt)
  • gcc, compilateur depuis 1985
  • Nemiver, debugger (par le port série)

Références