Projet système PC : 2014 - CATHEBRAS Joël, GALLET Samuel, MANSOUR Rémy

De Ensiwiki
Aller à : navigation, rechercher

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


CacatOS
ImageOS.png
Projet Système d'Exploitation 2014

Développeurs Joël CATHEBRAS
Samuel GALLET
Rémy MANSOUR

Réalisation d'un système d'exploitation

Bienvenue sur la page du système d'exploitation CacatOS !
En parcourant les lignes de cette page, nous aimerions vous présentez le projet sur lequel nous avons travaillé: la conception d'un système d'exploitation PC sur une architecture x86 de Intel.

Equipe

Cathébras Joël : filière SLE (Systèmes et Logiciels Embarqués) Joël CATHEBRAS

Gallet Samuel : filière SLE (Systèmes et Logiciels Embarqués) Samuel GALLET

Mansour Rémy : filière SLE (Systèmes et Logiciels Embarqués) Rémy MANSOUR

Gestion de projet

Diagramme de Gant

Ce projet avait la particularité d'être très détaillé dans son organisation et la description des étapes de développement. Cependant il était nécessaire de greffer notre organisation de groupe à cette organisation de projet.

Les étapes de développement étant très détaillées, l'idée de faire un diagramme de Gant pour mener à bien ce projet est apparue naturellement.

Ce diagramme a été réalisé dès le premier jour et nous a servi d'indicateur, voir même de repère dans les étapes de développement.
Il nous a permis de constater dès la troisième semaine d'être en avance sur notre programme et d'être plus ambitieux au niveau des extensions.

Environnement de travail

CacatOS a été écrit majoritairement en C.

Pour créer ce système nous avons utilisé :

  • Des machines virtuelles Qemu et Bochs pour tester rapidement notre système.
  • Un outil de création de clé bootable UNetbootin pour tester notre système dans les conditions réelles d'une machine.
  • Un débogueur Gdb ainsi que l'outils de désassemblage Objdump pour le mode User auquel Gdb n'avait pas accès.
  • Un logiciel de gestion de versions Git.
  • Les outils GNU Binutils pour builder notre projet.

Dans notre groupe, deux des machines sur lesquelles nous travaillons étaient sous MacOS X. Pour ces deux machines nous avons dû utiliser une chaine de compilation Android (i686-linux-android) car la chaîne Clang (native sur MacOS X) n'était pas compatible avec les outils du projet. De plus il a fallut changer le fichier kernel/build/kernel.lds car certains blocs d'instructions ne passaient pas à la compilation.

Voici ce qui a dû être rajouté :

        *(.data)
	*(.data.rel)
        *(.data.rel.ro)
        *(.data.rel.local)

CacatOS

Le projet système doit mener notre équipe à la réalisation d'un système d'exploitation minimal, nous l'avons appelé le CacatOS ! (tout lien avec une précédente version de ce projet est fortuit, il permet cependant de montrer que le bon goût est contagieux :D)

L'OS doit respecter les principales fonctionnalités suivantes:

Une fois ces spécifications mise en place, il nous était possible d'ajouter des extensions. Nous avons choisis de nous pencher sur les extensions suivantes:

  • La gestion de l'écran avec la mise en place du pilote VGA.
  • La gestion de la souris.
  • La gestion de la consommation d’énergie.

Dans la suite de cette page, nous allons présenter ces différentes spécifications et indiquer les différentes étapes à suivre pour que vous puissiez vous même réaliser ce projet.

Mais si vous êtes impatient d'utiliser notre OS, voici une page faisant un résumé de ses actions.

Introduction aux OS

SimpleOSLayer.png

Avant de rentrer un peu plus dans les détails nous allons d'abord présenter ce qu'est un OS (Operating System).

Un Operating System (ou système d'exploitation) est un ensemble de programmes qui dirige l'utilisation des capacités d'un ordinateur par des logiciels applicatifs(Wikipedia). Dit autrement, une personne achetant un PC veut être en mesure d'utiliser comme bon lui semble le matériel de son ordinateur. Et cet utilisateur veut aussi s'abstraire des contraintes matériels et utiliser facilement ce matériel à sa disposition. Le système d'exploitation est là pour ça !
Pour plus d'information concernant les systèmes d'exploitations Wikipedia

Dans le cadre de notre projet, nous ne prenons en compte que le matériel basique de fonctionnement d'un ordinateur:

  • Le processeur
  • La mémoire (RAM)
  • La console
  • L'écran VGA

Les autres périphériques habituellement présents dans un système d'exploitation (disque dur, port USB, carte son, processeur de calcul flottant...) ne sont pas pris en charge par notre OS, ce sont des extensions qui peuvent être ajoutées sans trop de difficultés mais avec un peu de temps devant soi.

Gestion des processus

Vous l'aurez compris dans la section précédente, et par votre propre expérience, un utilisateur veut pouvoir lancer des applications comme bon lui semble sur son ordinateur. Pour cela le système d'exploitation doit donner l'illusion que les différents programmes s'exécutent en parallèles. En effet, on ne souhaite pas qu'une application ne soit exécutée que quand une autre est finie, et si en plus cette application est en interaction avec l'utilisateur (soumise à de nombreuse attente), elle ne doit pas bloquer le fonctionnement des autres applications en arrière plan.
Afin de répondre à cette problématique, notre système d'exploitation gère les différentes application en cour en leur permettant de s'exécuter à tour de rôle selon un round-robin à par priorité.
Il donne aussi la possibilité de changer la priorité d'exécution des programmes. En effet, l'utilisateur peut vouloir qu'un programme s'exécute avant les autres, ainsi notre OS peut spécifier une priorité à chaque processus, et faire s'exécuter les programmes selon cette priorité.

Pour avoir un bon aperçu des notions utile pour cette partie, nous vous conseillons de faire les TPs de SEPC , ils vous permettront de vous familiariser avec les processus, l'ordonnancement, et le mécanisme interruption.

Pour plus d'information:

Gestion de la mémoire

Un des rôles essentiel d'un système d'exploitation est de gérer la mémoire RAM disponible. Une mauvaise gestion de la mémoire fait planter un ordinateur assez systématiquement, en effet, le processeur exécute un programme en récupérant le code, les données et la pile du processus dans la mémoire lui étant associé. En passant d'un processus à l'autre, le système d'exploitation doit sauvegarder le contexte d'exécution du programme (autrement dit il doit ranger le programme correctement) afin de pouvoir reprendre là où s'était arrêté le processus. Si cette transition est mal faite, le processeur exécutera des instructions incongrues et plantera à coup sur.
Afin de décharger l'utilisateur de cette responsabilité, le système d'exploitation est chargé de distribuer les zone mémoires pour chaque processus, et d'automatiser les changements de contexte.

La gestion mémoire permet aussi de virtualiser la mémoire disponible pour un processus grâce à un mécanisme nommé pagination. Cette mémoire virtuelle donne un niveau d'abstraction supplémentaire pour l’utilisateur, il permet à chaque processus de se croire seul à s’exécuter. Ainsi chaque processus aura un espace d'adressage similaire, ce qui facilite l'utilisation de la mémoire indépendamment de tel ou tel processus. En effet sans cette mémoire virtuelle, chaque processus devait utiliser la mémoire RAM en utilisant les adresses physiques des cases mémoires. Ceci entraîne une grande complexité dans le partage de la mémoire et dans son utilisation...

Pour réaliser cette partie, nous avons complété les information présente sur les page de l'EnsiWiki du projet système par les précisions du wiki OSDev. Lors de l’implémentation de ces fonctionnalités, il a fallu souvent se référer directement à la documentation Intel afin d’accéder aux informations officielles.

Protection

En parallèle de la gestion mémoire, l'OS doit garantir une bonne utilisation de la mémoire par les processus. En garantissant notamment que la mémoire alloué à un processus n'est pas accessible à un autre, que l'espace mémoire du noyau elle ne soit accessible par aucun processus utilisateur...
Ce dernier point est le point central de ce qu'on appelle la protection dans un OS: un utilisateur génère des processus en lançant ces programmes, et ces processus ne doivent en aucun cas être amener à modifier l'espace mémoire du noyau.
Le noyau d'un système d'exploitation est ce qui assure tout le bon fonctionnement du système dans son ensemble, il permet le roulement des processus, la gestion de la plupart des erreurs, et la gestion des périphériques.

Pour réaliser cette protection nous avons utilisé le mécanisme de pagination mentionnée dans la section précédente. Nous avons fais en sorte que les adresses virtuelles d'un processus ne soit traduisibles qu'en adresses physiques allouées à ce processus.

Cependant les processus ont parfois besoin de récupérer des informations du noyau, comme la liste des processus actifs par exemple. Pour cela nous avons mis en place un ensemble d'appel système qui permettent aux processus utilisateurs d'utiliser les fonctions du noyau en toute sécurité.

Difficultés rencontrées et conseils

Les premières phases du projet (1 à 3) n'ont pas posé de problèmes particuliers. Nous avions déjà pu voir les notions dans les TPs de SEPC et l'adaptation du code fut plutôt facile.
La gestion des files de message en phase 4 à elle était un peu plus complexe car les spécifications doivent être attentivement étudiées afin de réaliser les comportements attendus.

La phase 5, concernant la mémoire virtuelle et la protection, a été de loin la phase la plus longue et la plus complexe de ce projet. Les spécifications de l'Ensiwiki sont abondantes mais c'est un vrai labyrinthe pour retrouver les informations (n'en déplaise à nos encadrants...). Le premier conseil que l'on peut donner est de prendre son temps pour prendre connaissance tout ce que cette phase implique. Noter calmement chaque dimension pour voir comment s'articule l'ensemble.
Les difficultés rencontré lors de cette phase furent aussi au niveau de l'environnement de travail: deux des membre de notre groupe lancer leurs simulations sur Qemu sans accélération matériel (-no-kvm) car ils n'avaient pas accès a cette fonctionnalité. Lors des tests, il s'est avéré que certains bugs n’apparaissaient que lors des tests sur machine nue ou avec cette option d'accélération matériel.
Notre conseil est donc de se munir dès le début du projet d'une clef bootable afin de vérifier que votre OS passe bien les tests sur machine nue !
Pour information, nous avons passé presque trois jours entiers sur un bugs inaccessible avec le débuger gdb où avec le débuger de bochs (un autre émulateur d'architecture x86) car il apparaissait seulement sur machine nue. Il s'est avéré que nous ne remettions pas à 0 la mémoire des frames que nous allouions, ce qui induisait un comportement aléatoire lors de l'utilisation massive de frames.

Une fois la phase 5 fonctionnelles, les phases 6 et 7 n'ont pas étaient difficiles. Il nous faut peut être noté un manque d'inspiration pour la réalisation de commandes shell, mais nous avons préféré nous pencher rapidement sur les extensions.

En ce qui concerne les extensions, il était trop tard pour réaliser un système de fichier (dimension qui selon nous manque particulièrement à notre OS), nous avons chercher à réaliser un pilote souris, un pilote VGA et un pilote APM (Advenced Power Management).
La personne s'étant lancé sur le VGA voulait dans un premier temps réaliser un pilote VESA (une version amélioré du VGA), mais l'environnement de développement sous MacOS ne lui a permis que de réaliser le pilote VGA basique.
Concernant le pilote APM, nous avons été confronté au problème d'une technologie obsolète, car plus utilisé depuis Windows 95 (l'APM ayant été remplacé par l'ACPI advanced configuration and power interface). Nos machines n'utilisent plus l'APM et Qemu ne simule pas de périphérique batterie. Nous avons cependant réalisé les premières fonction du driver afin de ce familiariser avec ces notions.

Équipe encadrante

Damien Dejean

Gaëtan Morin