Projet Système PC : 2013 - Bourgaud, Fleury et Thiebaut

De Ensiwiki
Aller à : navigation, rechercher

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

Cette page ensiwiki a pour objet de présenter le projet de spécialité de Julien FLEURY, Quentin THIEBAUT et Adrian BOURGAUD.


NoN-OS
NoN-OS.png
La mascotte de notre OS


Introduction

Le système d'exploitation (SE ou OS en anglais) est le socle qui permet à un ordinateur ou autre calculateur évolué (tablette, téléphone portable) d'utiliser de façon robuste des applications avancées. Les systèmes d'exploitation pour PC les plus connus sont: Linux, Windows ou Mac.

Au cours de ce projet de deux semaines et demie nous avons codé un petit OS pour PC qui fonctionne sur machine nue. Nous avons appelé notre produit NoN-OS (NOt a Nice Operating System).

Enjeux

Les OS comme Linux ou Windows sont très évolués. Ils exploitent au maximum les possibilités du matériel (carte graphique, multi-processeurs, carte réseaux, et plus encore). De plus, de nombreuses applications sont déjà développées spécifiquement pour ces systèmes.

De fait, notre OS qui est simple ne peut pas les concurrencer: il n'a aucun intérêt pour les clients. Il n'est pas non plus innovant. Il n'y a donc aucun enjeu concret, mais l'intérêt pour nous les étudiants est grand:

  • Mettre en pratique les cours que nous avons eu sur les systèmes d'exploitation.
  • Avoir une meilleure vision d'ensemble sur le fonctionnement d'un OS.
  • Avoir une expérience dans le développement d'un projet de petite envergure.


Objectifs

L'objectif était de créer un système d'exploitation solide. Il devait permettre à un utilisateur de pouvoir lancer des applications simples pré-compilées, via une console. Autrement dit, installer de nouvelles applications n'est pas possible sans retoucher au code de l'OS.

La meilleure façon pour le profane de cerner les capacités de notre OS est de le caractériser par ce qu'il ne gère pas (C'est une des raisons pour lesquelles nous l'avons baptisé NoN-OS). Voici les fonctionnalités qu'il n'étaient pas prévues d'implémenter lors du projet:

  1. la sauvegarde du travail entre deux sessions (pas de disque dur)
  2. l'interface graphique
  3. l'accès au réseau (internet)
  4. le multimédia (son et vidéo)
  5. la souris

Cahier des charges

L'OS devait gérer principalement:

  1. La gestion des processus: Il s'agit de partager le temps d'exécution de chaque processus sur le processeur (unique), afin de simuler un fonctionnement en parallèle.
  2. La gestion de la mémoire: Afin de simuler que chaque processus dispose de toute la mémoire à sa guise.
  3. La protection de la mémoire: Les processus ont un espace mémoire réservé, ils ne peuvent à priori pas accéder à celui des autres processus, ni à celui du noyau.
  4. La communication entre processus: Via des files de messages, et la création d'espaces de mémoire partagé sécurisés.
  5. Un interpréteur de commande: Aussi appelé Console ou Shell. Il permet à l'utilisateur d'interagir avec le système, en faisant des saisies au clavier.

Indicateurs de réussite

Le projet est considéré comme réussi à 100% si l'utilisateur peut interagir avec le système via l'interpréteur de commande. L'interpréteur de commande doit être capable d'appeler des applications qui exploitent toutes les capacités de notre OS (gestion des files de message, des pages de mémoire partagées, de la filiation).


Réalisation

Dans cette section, nous détaillons l'état de notre OS à l'issu du Projet Système.

Extensions réalisées

  • Nous avons implémenté la gestion de plusieurs consoles, accessibles via les touches F1-F6. L'intérêt pour l'utilisateur est de pouvoir organiser son travail en dédiant chaque console à une plusieurs tâches bien précises.
  • Nous avons de plus implémenté un buffer de commande associé à chaque console. Cela permet à l'utilisateur d'accéder à des lignes de commande qu'il a entré auparavant, en navigant avec les flèches haut-bas.
  • Enfin, nous avons implémenté la possibilité d'allouer et libérer dynamiquement de la mémoire dans les processus utilisateurs. Cela permet par exemple aux processus utilisateurs de manipuler des chaînes de caractères de taille à priori inconnue.

Robustesse du code

Nous avons testé les fonctionnalités de notre OS tout au long de notre projet, afin de garantir une robustesse maximale. Notre OS a passé 4 vagues de test:

NoN-OS exécutant les tests fournis
  • Des tests unitaires réalisés tout le long du projet pour garantir que chaque fonction fonctionne individuellement.
  • 20 tests fournis par les professeurs, plus complexes et qui garantissent la cohérence des différentes implémentations entre elles.
  • Des tests de performance pour vérifier le bon fonctionnement de l'OS dans des cas limites.
  • Des tests des terminaux réalisés au fur et à mesure des exécutions des tests et fonctionnalités.

Fort de tous ces tests nous pouvons garantir le bon fonctionnement de notre OS. La section ci-dessous référence les bugs connus.

Bugs connus

Voici une liste des bugs connus de notre OS. Y est détaillé le contexte du bug.

  • Cons_read: Si un processus fait un cons_read, ce dernier n'est pas associé à la console parent du processus. Ainsi, si on lance deux processus qui appellent cons_read sur deux consoles différentes, écrire dans une console ne garantit pas que le processus correspondant reçoit le message.
  • Buffers de commande: Les touches non gérées par l'OS impriment des séries de caractères dans le buffer et rendent la commande inutilisable. Il faut faire un retour chariot et retaper la commande.

Bilan sur le projet

Dans cette section, nous faisons un retour sur la conduite du projet, en mêlant aspects technique et personnels.

Difficultés rencontrées

L'une des difficultés du projet était de corréler les informations dans la documentation fournie sur Ensiwiki: les spécifications, ou le cahier des charges sont parfois décrits à plusieurs endroits et difficiles à comprendre. Il était parfois difficile de cerner exactement les limites du projet.

Une autre difficulté rencontrée était de trouver des informations sur l'implémentation de Systèmes de Gestion de Fichiers (SGF) lorsque nous souhaitions les implémenter. Nous avons trouvé de la documentation sur plusieurs SGF mais il est difficile de cerner lequel serait le plus approprié pour notre OS, sans rentrer dans le détail du fonctionnement de chacun.

Enrichissement personnel

Ce projet nous a immergé dans un univers très technique. Cela nous a conforté dans nos capacités à comprendre des implémentations de code qui doivent être réalisés en corrélation directe avec le matériel (gestion des interruptions et de la mémoire). Nous avons de plus découvert le fonctionnement du passage entre niveau de privilège utilisateur et noyau. En effet, nous connaissions le principe mais ne savions pas comment il était mis en oeuvre.

Conclusion et Perspectives

Afin de pouvoir sauvegarder le travail réalisé entre deux sessions, nous aurions aimé installer un driver de disque dur ATA sur notre OS. Nous aurions de plus aimé implémenter un Système de Gestion de Fichier ce qui aurait permit à l'utilisateur de naviguer dans un environnement composé de répertoires et de fichiers. Malheureusement le temps imparti était trop court: nous estimons le temps nécessaire à implémenter ces deux extensions à quinze hommes-jour.

Cette petite déception mise à part, le Projet Système a pour nous été un challenge, l'occasion de mettre nos compétences et notre esprit d'équipe à l'épreuve. Nous sommes fier du produit rendu, qui est robuste bien que minimaliste.


Livrables


Références