Projet système PC : 2010 - Cumont Remy et Praga Alexis

De Ensiwiki
Aller à : navigation, rechercher

Ceci est une présentation de notre projet système. Celle-ci se veut accessible et intéressante, même pour le novice.

Notre OS a pour nom Ramol'OS (pour ses performances...).

Equipe : CUMONT Rémy, PRAGA Alexis


Qu'est-ce qu'un OS ?

Un système d'exploitation (Operating System, ou OS) est une interface entre les applications et le hardware d'une machine.

Il a été créé pour éviter aux programmeurs de devoir écrire tout leur code en fonction du matériel.

Notre projet

Objectifs 

Notre but est de réaliser un noyau avec peu de fonctionnalités mais réaliste. Les différentes parties sont :

  • Ecrire à l'écran
  • Créer, détruire des processus
  • Ordonnancer les processus
  • Gérer les files de message
  • Créer un mode user
  • Récupérer le texte entré au clavier
  • Faire un terminal
Contraintes 

L'architecture utilisée est la plus commune : le noyau utilise les instructions du processeur Intel 8086 (x86).

L'affichage graphique n'est pas pris en compte, nous affichons les résultats en mode texte.

Code fourni 

On ne part pas de rien ! L'allocateur mémoire et printf sont déjà fournis. L'initialisation est faite par les professeurs (heureusement...)

Extensions 

Le sujet comporte une partie obligatoire (cf Objectifs) et des extensions (à définir suivant le groupe). Il a été conçu pour des élèves ayant suivi le module PSE, matière ne faisant pas partie de notre filière (MMIS).

Dans notre cas, la gestion du clavier et le terminal correspondent aux extensions que nous aurions pu faire.

Environnement 

Comme nous créons le composant central d'un ordinateur, il existe 2 manières de tester l'OS.

  • Sur clé USB : il faut installer le fichier binaire du kernel, et un bootloader pour charger ce dernier
  • Sur machine virtuelle : on fournit à celle-ci le fichier binaire et un booloader. Celui-ci a été crée par les enseignants pour les machines ENSIPSYS.

Cela évite de redémarrer l'ordinateur pour tester à chaque fois (préférable pour les nombreux tests).

Le projet se fait globalement C, avec des petites parties en assembleur (appelées ou appelant du code en C).

Le débuggage est difficile :

  • au début, lorsqu'on n'a pas d'affichage
  • sur les parties en assembleur
Public visé 

Il s'agit d'un projet pour découvrir le fonctionnement d'un kernel. Toute personne désireuse de s'y intéresser peut regarder le code.

Durée 

3 semaines donc court pour ce genre de projet !

Fonctionnalités

Affichage

Nous avons créé une fonction appelée par printf.

Ainsi, nous pouvons écrire à l'écran, afficher un curseur. La quantité de texte n'est évidemment pas limitée à l'affichage de l'écran, mais ce qui a été effacé par un scroll ne peut pas être retrouvé. Voici un exemple montrant notre gestion de l'affichage.

Un jeu pour tester l'affichage
Gestion des processus

Nous pouvons créer, quitter, détruire des processus. Le passage de paramètres fonctionne, mais il est impossible de retourner une valeur.

Timer

A intervalles réguliers, un quartz génère des interruptions. Celles-ci permettent de mesurer le temps (cf Spécifications), mais aussi de gérer l'ordonnancement des processus.

De cette manière, on peut éviter qu'un processus reste trop longtemps actif. Cela permet aussi de ne pas avoir à faire "à la main" des changements de processus.

Files de messages

Ceci sert à pouvoir passer des messages entre les processus. On peut les utiliser pour faire des sémaphores, mutex (cf SEPC).

Problèmes rencontrés

Nous avons passé beaucoup de temps sur les 2 parties difficiles du projets.

Changement de processus

Le processeur ne peut contenir qu'un seul processus, il faut donc réaliser un bout de code en assembleur permettant de changer de "contexte" (i.e les registres importants) de processus.

Mode user

Jusqu'à cette étape, le projet se faisait dans le mode "kernel", c'est-à-dire qu'on appelait des fonctions, on écrivait sur l'écran sans problème.

Mais dans la vraie vie, il existe un mode "user", qui a des droits limités (pour des raisons de sécurité : on n'utilise pas les drivers comme ça !). On est la plupart du temps dans celui-ci.

Lorsqu'il faut faire des actions qui nécessitent des privilèges spéciaux (ou des fonctions du noyau), on va déclencher une interruption. Celle-ci sera récupérée en mode kernel et s'en chargera. Après cela, on redonne la main au mode user.

Limites

En cours de développement 
  • Mode user : celui-ci n'a pu être fini à temps.
Restent à développer 
  • Récupérer du texte entré au clavier
  • Terminal

Celui-ci a déjà été fait pendant l'année (TP de SEPC). Comme précisé dans la rubrique Extensions, il s'agit d'une partie facultative. Mais une fois le mode user fait, celles-ci n'auraient pas pris beaucoup de temps.


Conclusion

Ce projet est très technique. Étant de courte durée, il est guidé pour ne pas perdre de temps sur l'organisation des différentes phases.

Il s'adresse plutôt aux élèves d'ISI/Telecom, qui ont suivi des cours les préparant à ce projet. Ils ont de plus réalisé une bonne partie du sujet en TP (affichage, clavier, timer).

Le sujet étant intéressant et dans la continuité de la SEPC, nous avons décidé de nous y lancer.

Il ne faut pas s'attendre à des résultats visuels impressionnants. Au mieux, nous aurions eu un terminal en mode texte. Ce projet est abstrait, difficile mais formateur.

Nous regrettons seulement de ne pas avoir eu plus de temps pour faire un mode user fonctionnel et aborder les parties interactives (shell par exemple).

Annexes

Planning initial
Planning en fin de projet