Voir la source de Projet système PC : 2011 - Thibaut Charton, Benjamin Guebhardt

[[Catégorie:Projets de spécialité]]

{{Infobox Logiciel
| nom = WindOS
| logo = 
| image = [[Fichier:Capture-1.png]]
| description = 
| développeurs = [mailto:guebharb@ensimag.imag.fr Benjamin Guebhardt], [mailto:chartont@ensimag.imag.fr Thibaut Charton]
}}

==L'équipe, le projet==

Ce projet a été réalisé par:
*[mailto:guebharb@ensimag.imag.fr Benjamin Guebhardt] 
*[mailto:chartont@ensimag.imag.fr Thibaut Charton]

Ce projet se déroule dans le cadre de la 2e année à l'Ensimag, et consiste en le développement d'un système d'exploitation avec une base de départ aussi restreinte que possible.
Notre équipe a été encadrée, pour cela, par  [mailto:Gregory.Mounie@imag.fr Grégory Mounié]

== Les objectifs du projet ==

Ce projet consiste en le développement d'un système d'exploitation assez rudimentaire mais fonctionnel.
Les contraintes imposées ici le sont par un cahier des charges assez strict. Le principal objectif du projet est le respect de ce cahier des charges.
Notre OS fonctionne uniquement en ligne de commandes.
Les fonctionnalités imposées par le cahier des charges sont:
*La gestion de l'affichage (en mode ligne de commandes);
*La gestion de l'horloge interne du processeur;
*La création de processus, qui représente en fait la base du lancement d'applications par l'OS;
*L'ordonnancement des processus créés: 
**Notre machine de référence ne dispose que d'un processeur. Un seul processus peut s'exécuter à un temps donné, il faut donc implémenter une politique permettant au système de décider quel processus doit s'exécuter,
**L'algorithme choisi ici est relativement simple: à chaque processus, on affecte une priorité et c'est le processus de plus haute priorité qui s'exécute;
*La synchronisation entre processus: lorsque des processus ont besoin d'un accès à une ressource qui ne peut être partagée, on a besoin d'un outil, les sémaphores, permettant aux différents processus de se partager la ressource sans que deux processus y accèdent en même temps.
**Les sémaphores peuvent aussi être utilisés dans de nombreux autres cas;
*Les modes de privilèges: l'architecture utilisée (ici x86) permet certaines protections (protection de certaines zones mémoire, protection des entrées/sorties ...) afin de s'assurer d'un fonctionnement maîtrisé du système. Nous devons implémenter l'utilisation de ces modes de privilège.
**Cette partie constitue la plus complexe et la plus longue étape du projet;
*La gestion du clavier: le système doit pouvoir lire et gérer des caractères entrés au clavier, selon des règles précises;
*Le terminal: La dernière étape du projet est l'implémentation d'un terminal qui doit permettre d'utiliser certaines fonctions afin de démontrer le bon fonctionnement de l'OS.

Même si le cahier des charges est assez strict, nous avons un certain degré de liberté: nous sommes libres d'implémenter le cahier des charges de la manière que nous voulons, tant que les consignes données sont respectées.
De plus, tout ajout à notre initiative est ici le bienvenu, tant qu'il ne contredit pas la spécification du projet.
Enfin, une fois le cahier des charges rempli, nous pouvons choisir d'implémenter certaines extensions: gestion d'une interface graphique, de la carte son, d'un système de fichiers....

== Ce que nous avons réalisé ==
Notre groupe étant un binôme, le seul objectif imposé était l'implémentation du cahier des charges de base (contrairement aux trinômes qui devaient implémenter un minimum d'extensions).

=== Par rapport aux spécifications ===
Nous avons a maximum respecté les spécifications. Voici quelques exemples de celles-ci:

====Gestion de l'affichage et du timer====

[[Fichier:affichage_timer.png]]

Notre OS doit gérer l'affichage de caractères en mode textuel.
L'horloge intégrée au processeur doit être gérée, représentée ici par l'affichage en haut à droite du temps écoulé depuis le lancement du système

====Gestion du clavier et terminal====
[[Fichier:clavier_shell.png]]

Notre OS doit gérer l'entrée de caractères via un clavier.
Une fois cela implémenté, nous devons implémenter un shell permettant l'exécution de certaines fonctions démontrant le bon fonctionnement du système.
Ici, on a recouru à quelques commandes entrées au clavier:
*write permet d'afficher à l'écran les mots entrés après la commande
*ps affiche les informations relatives aux processus en cours
*help permet d'accéder au détail de l'utilisation d'une commande, notamment ici sinfo

====Procédure de tests fournie====

[[Fichier:tests_fournis.png]]

Tous les tests fournis fonctionnent et se terminent. En revanche, le test 7 (test de l'horloge) prend beaucoup de temps à s'exécuter.

=== Les extensions ===
Nous n'avons pas eu le temps d'implémenter des extensions telles que celles qui étaient proposées.
Cependant, nous avons étoffé les fonctionnalités du terminal en y ajoutant les commandes suivantes:

;clear: Efface tout l'écran. La première ligne est protégée et n'est jamais affectée.
;echo: Permet de régler l'affichage des caractères frappés:
:*echo off désactive l'affichage
:*echo on active l'affichage
:*echo toggle change l'affichage (si active, il le désactive, sinon il l'active).
;exit: Quitte le shell actuel. La seule interaction possible avec le système restante est les interruptions.
;help: Affiche les différentes commandes disponibles dans le système. La commande help <nom> permet d'obtenir le détail de l'utilisation de la commande <nom>.
;kill: Tue le processus entré en argument. En cas d'erreur, affiche un message correspondant à celle-ci.
;osinfo: Affiche le logo et les informations relatives a WindOS.
;ps : Ecrit a l’écran les informations utiles au sujet des processus existant dans le système. Si le temps d'attente est à 0, alors le processus n'est pas bloqué pour un temps donné.
;screate: Crée un sémaphore initialisé a la valeur passée en argument.
;sdelete: Supprime le sémaphore passe en argument.
;signal: Ajoute 1 à la valeur du sémaphore et libere le processus bloque de plus haute priorité le cas échéant.
;signaln: Ajoute la valeur du deuxième argument à la valeur du sémaphore et libère les processus bloqués de plus haute priorité le cas échéant.
;sinfo: Affiche des informations sur les sémaphores existants : leur numéro, les processus en attente et la valeur des compteurs.
;sreset: Libère tous les processus bloqués par le sémaphore passé en argument et le réinitialise a la valeur passée en second argument.
;start: Crée un processus dont la nature dépend du 2e argument.
:On peut ajouter un 3e argument '&' auquel cas le shell n'attend pas le processus qu'il vient de créer.
:Arguments possibles:
:*activable: crée un processus qui effectue quelques traces et se finit
:*bloque_sem: processus bloqué sur un sémaphore qui permet de tester les primitives concernées
:*bloque_fils: crée un processus qui crée un fils tel que le fils ne peut s'exécuter et l'attend afin d'observer ce qu'il se passe via le shell
:*endormi: crée un processus qui s'endort pour un certain temps
:*zombie: crée un processus qui se finit aussitôt
;sys_info: Affiche les informations utiles relatives au système Equivalent a osinfo suivi de ps puis sinfo.
;scount: Affiche la valeur du sémaphore passé en argument.
;test_proc: Lance le processus permettant de gérer les tests de référence.
;test_run: Effectue un des tests de référence. Le test lancé est celui du numéro passé en argument.
;test_run_tout: Effectue tous les tests de référence et s'arrête au test passé en argument.
;waitpid: Attend le processus entré en paramètre. Affiche ensuite la valeur de retour de ce processus.
;write: Affiche à l'ecran les mots qui sont tapés après la commande. Permet de tester la gestion des arguments.

== Ce que nous avons appris ==
Ce projet a été pour nous très riche en enseignements.
;Le fonctionnement d'un OS
:Au cours de notre scolarité, nous avons extrêmement peu d'occasions de nous plonger réellement dans le fonctionnement en profondeur d'un OS.
:Ce projet représente donc une expérience presque unique et nous a donc permis de comprendre en profondeur le fonctionnement d'un OS.
;L'importance d'un cahier des charges
:Le cahier des charges fourni pour ce projet était très strict.
:Il n'a pas toujours été évident de penser à toutes ses applications, et cela nous a donc beaucoup appris car nous avons pu faire certaines erreurs que nous espérons ne plus reproduire
;L'expérience de la programmation bas niveau
:De même que pour le fonctionnement d'un OS, il est assez rare que nous étudions en détail la programmation d'un ordinateur à un niveau aussi proche du matériel que pendant ce projet.
:C'est pourquoi nous avons aussi pu découvrir une facette de la programmation qui nous était encore relativement inconnue
;L'expérience du C
:Le langage utilisé, le C, est un des langages les plus utilisés, si ce n'est le plus utilisé pour ce genre d'applications.
:Cela nous a donc beaucoup apporté de réaliser un projet de cette envergure en C, car si Thibaut en avait déjà effectué pendant sa 1ere année à l'Ensimag, Benjamin, venant de Phelma, n'avait clairement pas cette expérience.

== Les difficultés rencontrées ==
Plusieurs facteurs ont contribué à ce que le projet soit pour nous un véritable défi:
;La composition du groupe
:Notre binôme était composé de deux personne aux parcours vraiment différent:
:Benjamin est un étudiant de Phelma, étudiant à l'Ensimag via la filière en commun SLE. Il n'a donc pas la même expérience de la programmation en général, et notamment du C et de l'assembleur qu'un élève issu de l'Ensimag.
:Thibaut est en filière MMIS, et n'a donc pas eu accès au projet PSE et aux cours/TD de CSE qui approfondissent beaucoup la problématique des systèmes d'exploitation.
:Cette disparité des compétences a rendu plus ardue la réalisation de ce projet, car si toutes les compétences étaient présentes, elles n'étaient pas forcément uniformes et nous avons donc dû passer beaucoup de temps à expliquer à l'autre ce qu'il n'avait pas vu pendant ses cours.
:Cette difficulté est aussi ce qui a fait que le projet est intéressant: nous avons tous les deux énormément appris de ce que l'autre pouvait lui apporter.
;La nature du projet
:Le sujet, assez unique, est un sujet assez inhabituel et il nous a parfois été assez dur de résoudre certains bugs que nous avions du mal à comprendre
;L'environnement de travail
:Si l'environnement de travail était adapté au projet, il imposait certaines limitations qui ne sont pas présentes dans un projet plus commun.
:Cela est principalement dû au fonctionnement de l'OS qui se faisait sur machine nue (ou virtualisée pour plus de commodité).
:Il nous était notamment difficile de recourir au debugger dans certains cas car cela soulevait certains problèmes (par exemple les interruptions dues à m'horloge qui ne sont pas arrêtées par les points d'arrêt du debugger). Cela faisait que parfois le debugger causait certains bugs, que nous cherchions à résoudre alors qu'ils étaient dûs à son fonctionnement même.
:Enfin, nous avons eu quelques difficultés à prendre en main le logiciel de version qui nous était fourni, par rapport à ceux que nous avions pu utiliser avant, et nous avons donc perdu du temps pour résoudre certains conflits à ce niveau

== Sources externes ==

L'ASCII Art représentant le logo de WindOS est issu de http://ascii.co.uk

== Kernel de l'OS compilé ==

Vous pouvez trouver le kernel [[Fichier:kernel.bin.gz | ici]] pour l'essayer sur un émulateur type Qemu ou Virtualbox