Projet système PC : 2016 - DUFOUR Maxime, ECHERNIER Benoit, SCHNEIDER Valentin

De Ensiwiki
Aller à : navigation, rechercher
Windoge
Windoge.PNG
Projet Système d'Exploitation 2016

Développeurs DUFOUR Maxime
ECHERNIER Benoit
SCHNEIDER Valentin

Présentation

Objectifs

Ce projet consiste à implémenter un système d'exploitation très basique, nous permettant de nous confronter à beaucoup d'éléments théoriques étudiés en SEPC et en CSE.

Cahier des charges

Le cahier des charges de ce projet est assez détaillé, découpant le projet en 7 phases qui sont à traiter, pour la plupart, séquentiellement. Voir Projet système : spécification.

Il est également imposé d'implémenter des extensions. Nous avons ici décidé d'améliorer les fonctionnalités du shell (historique, navigation...), d'implémenter un système de fichiers, et d'implémenter un pilote de speaker PC.


Gestion de projet

Organisation

Comme pour la plupart des projets de l'Ensimag, nous avons utilisé le gestionnaire de version Git. Pour ce qui est du matériel, nous avons utilisé nos ordinateurs personnels, et occupions une salle de TD dans le bâtiment H. Un groupe Whatsapp a été également créé pour communiquer en soirée ou pendant les week-ends.

Planning prévisionnel

Gant prevision PS dufou echern schneider.png

Planning réalisé

Gant realisation PS dufou echern schneider.png

Conseils

Prévoir du temps pour la phase 5, travailler ensemble, avoir plusieurs avis sur le même point. Un support graphique (i.e. un tableau) est fortement bénéfique lors des phases de réflexion / débuggage des étape plus complexes comme les files de messages la mémoire virtuelle.


Etat du projet

Phase 1 - Affichage à l'écran

100 %

Pas de difficultés notables, il s'agit là de récupérer l'implémentation de console_putbytes réalisée en Pratique du Système plus tôt dans l'année.

Phase 2 - Gestion des processus, changement de contexte

100 %

Pas de difficultés notables. À noter que mem_alloc prend en argument une taille en octets. Autrement, il s'agit d'une version un peu plus complexe de ce que vous avez déjà pu implémenter en pratiques du système en ce qui concernait la gestion des processus.

Phase 3 - Ordonnancement, cycle de vie d'un processus, filiation

100 %

Pas de difficultés notables. Comme précédemment, il s'agit d'une adaptation puis d'une extension du travail réalisé au préalable en pratique du système.

Phase 4 - Files de message, endormissement

100 %

On vous demande à cette étape d'implémenter des primitives de synchronisation entre les processus permettant de bloquer des processus et l'échange de messages entre ces derniers. Le format imposé par les spécifications consiste en des files de message. C'est une restriction à des messages de taille fixe du pipe d'Unix. Il faudra à cette étape revenir un peu sur votre implémentation des processus pour gérer le blocage de ces derniers dans les files de messages (que ce soit un blocage en lecture ou en écriture).

Doge helper.jpg

Conseils de maître-ingénieur Doge


Files de Message : Les spécifications sont assez précises sur cette phase. Le seul point à noter c'est la notion d'immédiatement. Ce qu'il faut comprendre c'est que si un rédacteur est bloqué (file pleine) alors le prochain lecteur devra prendre le message du rédacteur et mettre ce rédacteur en RUNNING. De même pour un lecteur bloqué à cause d'une file vide.



Phase 5 - Mémoire virtuelle, mode utilisateur

100 %

Avant cette étape, toutes les applications étaient exécutées en mode kernel donc elles avaient tous les droits. De plus, ces applications pouvaient accéder à des données d'autres applications.

Comme vous l'aurez compris, l'objectif de cette étape est d'apporter à l'OS une sécurité avec l'isolation des processus grâce à la mémoire virtuelle, mais également avec un mode user qui restreindra les droits des applications.

Doge helper.jpg

Conseils de maître-ingénieur Doge

Mémoire virtuelle : avant toute chose, rangez vos claviers. Commencez par bien tout lire, à vous documenter et à bien comprendre ce que l'on attend de vous à cette étape. Il s'agit d'un morceau assez gros à digérer. Sortez vos convertisseurs hexa, et préparez-vous à parcourir la table des pages à l'aide de GDB, votre meilleur ami lors de cette étape. Cette étape requiert des changements plutôt conséquents dans votre implantation. Pour l'allocateur de pages, nous vous conseillons de faire une adaptation de celui que vous avez développé en SEPC (pour n'allouer que des chunks de 4Ko et pas de taille variable entre autres, mais aussi qui correspond aux adresses physiques du 'tas' où les pages vont être allouées en mémoire, à savoir au-dessus de 64Mo et jusqu'à 256Mo - 192Mo dans notre implantation afin d'avoir une puissance de 2 pour satisfaire les prérequis de l'algorithme de buddy).


Mode utilisateur : pour passer au mode utilisateur, il n'y a pas beaucoup de code à écrire, mais dans la réalisation vous allez sans doute avoir de nombreux écrans bleus. Voici quelques conseils :

  • pour passer une application en mode user la première fois, il faut simuler une interruption (on fait croire au processeur que l'on était déjà en mode user, et qu'on retourne d'un appel système), pour cela, on procède de la manière suivante (étapes à réaliser dans cet ordre) :
    • mettre l'esp0 dans la tss
    • mettre SS0 dans la tss
    • mettre 0x4b dans ds, es, fs, gs
    • mettre sur la pile les registres suivants (SS [0x4b], ESP, EFLAGS, CS [0x43])
    • mettre sur la pile l'adresse du début de fonction du processus à exécuter en mode user
    • iret

Votre application est lancée en mode user, félicitations !!!


Appels système : Les appels systèmes ne sont pas difficiles à coder, il faut simplement vérifier à bien sauvegarder les registres utilisateurs mais aussi de mettre les bons arguments au handler de l'interruption 49. À noter qu'au retour de l'interruption, le registre eax contient le code erreur de l'appel système.


Enfin : Lorsque toutes les étapes précédentes sont fonctionnelles, il reste un point à traiter : les interruptions classiques. En effet, il ne faut pas oublier d'ajouter le changement des registres de segments pour les passer en mode kernel. En effet, les applications user étant interruptibles, lorsqu'une interruption arrive (exemple : horloge) tous les registres de segments ne sont pas mis automatiquement à la bonne valeur par l'interruption (seulement SS à 0x13). Il faut donc en début de traitant d'interruption, bien mettre DS, ES, FS et GS à 0x18 pour signifier que l'on est en mode kernel dans le traitant d'interruption. Enfin, à la fin du traitant, on remet bien DS, ES, FS et GS à 0x4b pour repasser en mode user après l'iret, (en effet, l'iret ne s'occupe que de SS).

Docs utiles : Manuel Intel pour le développeur système, Manuel Intel des instructions IA32

Phase 6 - Pilote de clavier

100 %

Il est demandé à cette étape de permettre une communication avec le système via un clavier. Il faut donc gérer les interruptions clavier, et stocker les caractères associés aux touches dans un buffer.

Doge helper.jpg

Conseils de maître-ingénieur Doge


La spécification de cons_read n'est pas vraiment limpide, cependant les conseils de ce groupe sont très utiles : Projet système PC : 2015 - DEFOURNE Maximilien, MIRGHANE Kaizar, FOUASSIER Raphaël. Il est important de respecter la priorité des processus qui utilisent cons_read, le plus simple est donc de suivre un mode 'canonique' : ce qui est affiché à l'écran est le buffer du terminal, et seul un appui sur entrée (ou un caractère de contrôle, pour implémenter les Ctrl-C et autres) vide le buffer dans le processus bloqué sur cons_read le plus prioritaire. Aussi, pour éviter de creuser partout sur le wiki : le clavier utilise l'interruption 33 et l'IRQ 1.


Phase 7 - Shell

100 %

Cette étape est une version simplifiée du shell fait en SEPC.

Extensions

Shell amélioré

Pour ce shell amélioré, nous avons implémenté ces différents points :

  • un historique des commandes (CTRL+P = remonter l'historique et CTRL+N = descendre l'historique)
  • une navigation forward, backward dans une commande (Flèche Gauche / Droite)
  • affichage de la date

Voici un screenshot du résultat de la commande 'help' de notre système, listant les fonctionnalités utilisables par l'utilisateur de ce dernier :

Windoge help.PNG

PC Speaker

Il s'agit là d'utiliser le haut-parleur interne du PC. Il faut noter que ces haut-parleurs semblent être de moins en moins présents sur les ordinateurs récents : nous avons perdu du temps à chercher d’éventuelles erreurs dans notre code alors qu'il était fonctionnel, il nous a fallu tester sur un autre ordinateur qui lui possédait ce haut-parleur. Toutes les informations nécessaires au fonctionnement du speaker se trouvent sur OSDev : OSDev : PC Speaker. Il est également bon de lire OSDev : PIT Channel 2 pour mieux comprendre le fonctionnement du speaker.

Gestionnaire de fichiers

Notre gestionnaire de fichiers se base sur le fonctionnement du système FAT. Cette extension n'est pas très difficile, il faut simplement comprendre le fonctionnement du système FAT (l'utilisation d'un tableau ou d'un autre support d'écriture en plus d'un hexdump d'une image d'un disque est fortement conseillée). De plus notre OS est dépourvu de pilote USB ainsi nous avons opté pour copier une copie d'un disque formaté en FAT16 (nous utilisons pour cela un script shell maison qui formatte un fichier en une partition FAT16 de 8Mo. Le script ajoute des fichiers et des répertoires sur la partition afin d'avoir une arborescence de démonstration. Ce fichier est ensuite transformé en un fichier assembleur par le script, et ce fichier assembleur est ensuite compilé dans le kernel). Cette copie de disque est ainsi chargée dans la RAM directement au démarrage du système, en même temps que le kernel est chargé dans la RAM.

Les fonctionnalités associées sont :

  • ls
  • mkdir
  • touch
  • write
  • cat
  • pwd

Pour réussir à faire fonctionner ce gestionnaire de fichiers, nous nous sommes beaucoup documentés sur les spécifications de FAT. Vous trouverez des informations pertinentes sur OSDev et sur CodeAndLife.

Néanmoins, notre système de fichiers ne gère que la FAT16 (FAT12 et FAT32 peuvent être ajoutés avec un peu de code en plus).

Le screenshot suivant montre le fonctionnement de notre script de générations d'images de floppy disk formattées au format FAT16 :

Windoge floppy creation.PNG


Voici des screenshots illustrant les fonctionnalités de notre système de fichier :

On peut voir sur l'image suivante une partie de l'arborescence présente de base dans la floppy disk à l'aide de 'ls' :

Windoge filesystem 0.PNG


Se déplacer et connaitre sa position dans l'arborescence avec 'cd' et 'pwd' :

Windoge filesystem 1.PNG


Afficher le contenu de fichiers textes avec la commande 'cat' :

Windoge filesystem 2.PNG


Supprimer des fichiers et des dossiers à l'aide de 'rm' et 'rmdir' :

Windoge filesystem 5.PNG


Créer des fichiers textes et des dossiers avec 'touch' et 'mkdir' :

Windoge filesystem 3.PNG


Ecrire dans un fichier avec 'write' :

Windoge filesystem 4.PNG

Conclusion

Apports du projet

C'est le premier projet qui nous a posé un vrai souci (1 semaine pour faire fonctionner la phase 5). Ensuite, ce projet permet de mettre en pratique les parties théoriques de SEPC et de CSE non abordée en TD/TP. Enfin, nous avons maintenant la satisfaction d'avoir réalisé un OS qui est certes basique, mais fonctionnel.

Mais pourquoi Windoge ?

Doge est un meme internet, et sa sonorité colle bien avec Windows. Il existait beaucoup d'images exploitant ce "jeu de mot", mais aucun vrai OS du nom de Windoge, ce qui est maintenant réglé !

Essayer Windoge

Vous pouvez télécharher le kernel.bin de Windoge à l'adresse suivante : Fichier:Windoge 10 kernel.zip.