Projet système PC : 2016 - GOUTTEFARDE Léo, OMAR Azizi, QUAY-THEVENON Etienne

De Ensiwiki
Aller à : navigation, rechercher
Atomic'OS
Atomic.png
Projet Système d'Exploitation 2016

Développeurs GOUTTEFARDE Léo
OMAR Azizi
QUAY-THEVENON Etienne

Présentation

Bienvenue sur la page de présentation de notre système d'exploitation développé dans le cadre du projet de spécialité de deuxième année.

Sans plus attendre n'hésitez pas à télécharger Atomic'OS afin d'en profiter sur machine réelle, QEMU et Virtualbox.

Pour créer une clé USB bootable un moyen simple consiste à utiliser le logiciel Rufus pour installer l'ISO fourni. Une telle image ISO s'obtient facilement en suivant les instructions disponibles sur OSDev.

Équipe

GOUTTEFARDE Léo : Filière ISI
OMAR Azizi : Filière ISSC
QUAY-THEVENON Etienne : Filière ISI

Gestion de projet

Nous avons testé notre système en continu sur QEMU avec accélération matérielle, mais également sur Virtualbox et sur machine réelle. Il fonctionne dans tous les cas sans problème, même sur les machines de l'Ensimag.

Planning prévisionnel

Nous avons réalisé le planning prévisionnel suivant :

Planning previ 777.png

Planning effectif

Nous avons finalement suivi le planning effectif suivant :

Planning 777.png


La partie la plus longue est en réalité la gestion du mode graphique en raison des recherches documentaires nécessaires et des difficultés techniques à affronter. Elle comporte aussi une partie de debug relativement longue, surtout lorsque des crashs inexistants sur QEMU et Virtualbox surviennent sur machine réelle.

La phase 5 quant à elle est la plus complexe à comprendre techniquement, mais s'effectue assez rapidement en suivant les nombreuses indications données sur l'Ensiwiki (le plus long étant le debug, notamment une simple erreur d'inattention au sein du kernel peut corrompre le reste du travail effectué).

Présentation des différentes phases

Phase 1 : Affichage à l'écran

Rien de complexe dans cette phase, nous avons simplement intégré le code réalisé en Pratique du Système au S3.


Développement :

100 %


Tests :

100 %

(22/22)


Phase 2 : Processus et changement de contexte

De même pour cette phase, nous avons également intégré le code réalisé en Pratique du Système au S3.


Développement :

100 %


Tests :

100 %

(22/22)


Phase 3 : Ordonnancement, gestion et filiation des processus

Pour cette phase nous avons d'abord récupéré le code réalisé en Pratique du système, mais il a fallu en adapter de nombreuses parties (notamment pour utiliser les files de priorité dans la gestion des processus). De plus il a fallu lire bien attentivement les différentes pages de spécification afin de réaliser la filiation et la gestion des processus de la manière attendue.


Développement :

100 %


Tests :

100 %

(22/22)


Phase 4 : Communication et endormissement des processus

Pour cette phase la réalisation de la communication entre les processus via les files de messages ne semblait d'abord pas si complexe. Nous avons cependant perdu beaucoup de temps dessus en raison d'une spécification peu claire, alors qu'il était en fait possible de réaliser cette partie très rapidement une fois le fonctionnement bien compris. Finalement cette page nous a permis de trouver la bonne manière de procéder pour traiter cette partie correctement.

Pour l'endormissement nous avons simplement utilisé les files de priorité.


Développement :

100 %


Tests :

100 %

(22/22)

Phase 5 : Mémoire virtuelle, syscalls et mode user

Cette phase est de loin la plus complexe notamment au niveau technique. Nous avons eu beaucoup de mal à debugger les problèmes au niveau des syscalls dans un premier temps car gdb les bloque en exécution pas à pas. Il faut bien lire toutes les pages traitant de ce sujet (Ensiwiki + OSDev) et bien comprendre pour pouvoir mener à bien cette partie.

La gestion de la mémoire physique a été implémentée en réutilisant le gestionnaire de mémoire de type buddy réalisé en cours de SEPC.

Le partage de mémoire a été implémenté assez facilement à l'aide du module de hash fourni ainsi qu'avec les conseils des années précédentes (bien faire attention à copier en mémoire kernel les chaînes de caractère passées en argument qui sont des adresses utilisateur invalides d'un processus à l'autre).


Développement :

100 %


Tests :

100 %

(22/22)

Phase 6 : Pilote de console

Cette phase n'a pas posé de problème particulier, il faut simplement lire la documentation fournie et gérer le traitant d'interruption clavier correctement.


Développement :

100 %


Tests :

100 %

(22/22)


Phase 7 : Développement d'un shell

Le développement d'un shell de base est relativement simple. Cependant les différentes améliorations d'extension possibles demandent parfois un certain travail pas toujours évident au niveau de la communication entre le shell user et le pilote de console kernel.


Développement :

100 %


Extensions

Shell amélioré

Nous avons ajouté de nombreuses fonctionnalités à notre Shell :

  • Auto-complétion
  • Historique des commandes avec les flèches haut / bas
  • Effacement avec la touche backspace
  • Affichage de la bannière de l'OS
  • Redémarrage de la machine avec la commande reboot
  • Nettoyage de l'écran avec la commande clear
  • Affichage de la liste des modes graphiques disponibles : commande vesamodes
  • Passage en mode graphique par autodétection : commande vesa
  • Passage en mode graphique manuel : commande vbe <mode>
  • Gestion des fichiers : commandes cat, ls, touch

Mode graphique HD

Nous sommes parvenus à passer en mode graphique VESA avec des résolutions assez élevées grâce à l'API permettant d'effectuer des appels bios en mode réel (merci à Simon Nieuviarts pour cette API).

Cela n'a pas été si simple de par les différentes contraintes imposées par le mode réel 16 bits notamment. Nous voulions intégrer un décodeur JPEG pour pouvoir afficher de grandes images de petite taille mais malheureusement sans librairie math, pas de fonctions cos / sin et donc notre décodeur n'a finalement pas pu être intégré (l'intégration en C de la classe Math Java / Deca développée en Projet GL semblait une perte de temps).

Nous avons aussi géré l'affichage d'un curseur de souris, nous voulions créer un interface graphique complète avec notamment la gestion du double buffering mais n'avons pas eu le temps d'aller aussi loin dans la documentation du mode VESA.

Le code d'auto-détection d'un mode graphique disponible sur OSDev a notamment été intégré et amélioré, de même certaines parties du code de la documentation VBE ont été adaptées mais les structures de données ont globalement été prises sur OSDev.

De nombreuses informations ne sont disponibles que sur la documentation VBE, ainsi il est recommandé de la consulter régulièrement en complément aux recherches effectuées.

Visionneuse d'images en HD

Une visionneuse d'images a été implémentée pour tirer parti du mode graphique.

Pour l'utiliser, il suffit de taper la commande ls afin de savoir quelles sont les images disponibles puis de taper la commande : display <chemin>

L'image s'affiche alors à l'écran, pour revenir en mode console il suffit d'appuyer sur la touche escape. Un pointeur de souris graphique est également affiché comme toujours en mode graphique.

Nous n'avons pas intégré d'images de très grande taille car nous n'avons eu le temps de trouver une méthode de compression simple à intégrer au sein du noyau (un RLE simple ne suffit pas).


Captures d'écran :

Rider 777.png Wolv 777.png Light 777.png

Pilote de souris PS/2

Nous avons développé un pilote de souris PS/2. Pour cela nous avons repris une partie du code disponible sur le tutoriel suivant : Tutoriel OSDev.

Cette partie n'a pas été évidente même avec l'aide disponible sur OSDev, car il faut d'abord bien effectuer l'acquittement auprès des 2 PICs lors de chaque interruption et aussi il faut démasquer les IRQ 2 et 12 : la 2 sur le PIC 1 afin d'activer le PIC 2, et la 12 correspond à la 4 du PIC 2.

De plus, des paquets erronés peuvent survenir au cours du temps, ainsi pour avoir un pilote de qualité il faut rejeter les paquets invalides en vérifiant les différents bits disponibles pour cela.

Système de fichiers

Nous avons développé un système de fichiers simple en mémoire RAM, suivant une API similaire à la librairie standard.

Snake

Nous avons développé un jeu de Snake en mode console.

Jeu serpent atomicOS first.png Jeu serpent atomicOS.png

Affichage de l'heure système

Nous avons récupéré l'heure exacte de l'horloge système pour pouvoir l'afficher correctement (documentation disponible sur OSDev).

La plupart du code est fournie sur OSDev, il suffit simplement de l'intégrer au sein du kernel.

Sémaphores

Nous avons ajouté le mécanisme de synchronisation des sémaphores (passant également tous les tests).

Références

Ci-dessous d'autres pages qui nous ont été très utiles au cours du projet :