Projet système PC : 2013 - Rémy BERTOMEU, Uldéric KIBONGUI et Didier PARAT

De Ensiwiki
Aller à : navigation, rechercher
Tuladanl'OS
Tuladanlos(1).png
système d'exploitation

Développeurs Rémy BERTOMEU
Uldéric KIBONGUI
Didier PARAT

Cette page présente la réalisation de l'OS Tuladanlos.
Elle est organisée en deux grandes parties, la réalisation des fonctionnalités demandées dans le cahier des charges et les extensions ajoutées.

Dans chaque partie est donné un détail du processus d'implémentation de la fonctionnalité concerné ainsi que les éventuelles difficultés rencontrées.

Enjoy.

Réalisations

Cahier des charges minimal

Affichage à l'ecran

Cette étape a été la première et a été développée à 3.
En effet, pour prendre en main le code il était plus simple de tous travailler sur un même PC.
Pas de tests unitaires pour cette parties mais des tests à la main pour vérifier tous les cas.

Pas vraiment de difficulté sur cette étape à part la prise en main du code (comme sur tout nouveau projet).

Gestion des processus, ordonnancement & changement de contexte

Une seconde fois, toute l'équipe a travaillée ensemble autour d'une même machine, pour gérer le changement de contexte.
Cette étape n'a pas été faite d'un trait, jusqu'au dernier jour, des changements ont été apportés aux fonctionnalités
composants cette étape. Le changement de contexte a été très long à comprendre, et donc à être opérationnel.

De nombreuses difficultés ont donc été rencontrées lors de cette étape.
On compte notamment la sauvegarde et restauration de contexte, ainsi que la gestion du cycle de vie d'un processus.
Sur ce dernier point, les spécifications du projet ont mal été comprises et manquaient quelques fois de clartés
ce qui a conduit a des erreurs d'implémentations ou des oublis de gestions de certains états.

Tests Unitaires

Pour maîtriser la validité de chaque nouvelle fonctionnalité, des tests unitaires ont été mis en place.
Ainsi, pour chaque fonction rajoutée (chprio, waitpid, etc...) un test est écrit et est ajouté à l'ensemble des tests unitaires.
Le résultat de chaque test indépendant ainsi que le résultat global est affiché à l'écran et permet de contrôler l'état du code.

La principale difficulté ici a été de mettre en place le système de test, une fois fait, l'ajout de nouveaux tests est trivial.

Sémaphores

Les sémaphores ont été réalisées en plusieurs parties.
Tout d'abord, les fonctionnalités basiques (screate, wait, signal) ont été implémentées en fonction des spécifications du projet.
Ensuite, elles ont été testées, puis corrigées. C'est seulement après cela que le reste des fonctions ont été écrites.
Une fois les sémaphores complètements codés, les tests fournis dans le projets ont été lancé afin de les tester complètement.

Les sémaphores ont posées beaucoup de difficultés. Soit parce que les spécifications avaient été mal lues, soit parce qu'elles n'étaient
pas assez détaillées.

Les tests fournis dans le projet ont permis de mettre en avant une mauvaise implémentation de l'algorithme de gestion des sémaphores.
Le premier algorithme écrit était très lent et a donc été remanié afin d'être plus efficace.
Au final l'utilisation de tableau et de liste a été choisie pour gérer les sémaphores.

Mode utilisateur/kernel

Le mode utilisateur permet de lancer des programmes avec un nombre restreint de privilèges : un programme utilisateur ne peut pas réaliser certaines instructions telles que "cli" (démasquage des interruptions) qui lui permettraient potentiellement de prendre le contrôle du système d'exploitation.

Chaque programme dispose d'une pile utilisateur (allouée en zone utilisateur), ainsi que d'une pile kernel qui est utilisée lors des appels systèmes (qui nécessitent un retour en mode kernel).

Nous avons eu quelques difficultés à comprendre l’enchaînement des opérations à réaliser pour basculer en mode utilisateur (écriture de l'ESP de la pile kernel dans la TSS, configuration de la pile kernel pour préparer le iret, iret).

De plus, nous avons expérimenté lors de notre phase de tests, un bug dans un test qui a exhibé un problème dans un choix de conception que nous avions fait.

Entrée/Sorties clavier

Les caractères tapés au clavier sont stockés avant d'être lus par un processus.

L'implémentation de ce mécanisme s'est faite via un buffer circulaire. Chaque interruption levée par l'appui d'une touche sur le clavier appelle la fonction "keyboard_data", qui se charge à la fois de l'affichage du ou des caractère(s) à l'écran en mode cons_echo et du stockage dans le buffer. Le buffer est ensuite vider via un appel à la fonction "cons_read".

Le Shell appelle "cons_read" et est bloqué jusqu'à ce qu'une commande soit validée via la touche "entrée". Les commandes peuvent être lancé en background en rajoutant le sigle "&" à la fin.

Plusieurs liens peuvent être intéressants à regarder pour l'implémentation du terminal notamment : Projet système : Aspects techniques, Gestion de l'écran, Gestion du clavier

A noter également qu'il n'y a pas besoin de buffer pour les appels à "cons_write" dans la version PC.

Voici la liste des commandes disponibles :

Commande Description

help

Affiche l'ensemble des commandes disponibles dans le Shell

bootscreen

Relance l'animation disponible lors du démarrage de l'OS

clear

Efface l'écran

ps

Affiche la liste de tous les processus du système avec leur PID, nom, priorité et état

echo

Active ou désactive l'affichage des caractères entrés au clavier

exit

Sort du shell et redémarre l'OS

sinfo

Affiche l'ensemble des informations relatives aux sémaphores, et aux processus bloqués sur sémaphore

test X

Lanche le test X. Si la commande est lancée sans argument, tous les tests sont lancés

color X

Change la couleur de la police de caractère. Les couleurs disponibles sont "red", "blue" et "green"

send

Lance un processus permettant d'envoyer des paquets ethernet

gfx

Lance la démo VGA

Extensions

VGA

Cette extension exploite le mode vidéo 13h permettant d'afficher des images en 320*200 256 couleurs. L'activation / Désactivation de ce mode vidéo se fait au moyen d'un BIOS call.

Nous avons implémenté des appels système permettant d'activer ce mode, ainsi que d'afficher un buffer pré rempli à l'écran. La bibliothèque graphique est implémentée du côté utilisateur et permet d'afficher des rectangles pleins.

Le dessin dans un buffer (et pas directement dans la mémoire vidéo) permet de faciliter la séparation kernel/user : l'utilisateur n'a pas besoin d'effectuer un appel système à chaque fois qu'il veut afficher un pixel, mais seulement quand il a fini de construire toute son image. Ceci permet de gagner en performance. L'autre avantage est que l'image est affichée à l'écran uniquement quand elle est terminée, ceci réduit les effets de scintillement (Double Buffering).

Ethernet

Nous avons développé une extension permettant à notre OS d'envoyer des messages vers l'extérieur. Qemu émule plusieurs modèles de cartes réseau, dont l'assez simple NE2000 sur port ISA.

Nous avons exploité la documentation ainsi que différents drivers libres pour ne2k_isa afin d'envoyer des trames vers l'extérieur. Ces trames sont ensuite lues à l'aide de Wireshark dans le système hôte.

Afin de rendre le système accessible au mode utilisateur, nous avons implémenté un système permettant d’émettre un message vers une adresse MAC, notre bibliothèque s'occupant elle de créer la trame Ethernet valide.

Nous n'avons cependant pas réussi à permettre à deux machines virtuelles de communiquer ensemble.