Projet système PC : 2012 – Michel DAVIT, Tonatiuh Rafael SANCHEZ TORRES et Marcos Arturo VEGA LOPEZ

De Ensiwiki
Aller à : navigation, rechercher


marcOS
MarcOS.png

Développeurs Michel Davit,Tonatiuh Rafael Sanchez Torres, Marcos Arturo Vega Lopez

Présentation

Bienvenue sur la page de notre projet système! Nous sommes trois étudiants en 2e année à l'Ensimag, et dans le cadre du projet de spécialité, nous avons réalisé un noyau de système d'exploitation. Nous avons nommé notre noyau marcOS, en l'honneur d'un des développeurs de l'équipe :).

Nous exposerons dans ce wiki les fonctionnalités de notre noyau ainsi que quelques points de programmation utiles pour le développement d'un système d'exploitation.

Notre tuteur lors de ce projet était Franck Rousseau.

Si vous avez envie de tester marcOS : Media:kernel.tar.gz (binaire de notre noyau).

Et la procédure d'installation sur Virtual Box.

Objectifs

L'objectif du projet n'est pas de réaliser un noyau Linux en 4 semaines mais un noyau simplifié réalisant supportant ces fonctionnalités de base:

  • Gestion des interruptions
  • Partage du temps entre processus
  • Gestion des privilèges (Kernel / User)
  • Gestion d'un shell

Nous avons aussi ajouter quelques extensions à marcOS:

  • Gestion de la mémoire virtuelle
  • Pilote de carte son (Creative Sound Blaster16)
  • Gestion de la souris

Réalisation

Fonctionnalités de base

Nous n'allons pas développer dans cette partie comment gérer les interruptions dans un système d'exploitation, ni comment effectuer le partage du temps entre processus. Cela est déjà bien détaillé dans les TPs de pratique du système.

Comme l'impose notre cahier des charges, nous avons dû implanter dans notre noyau un certain nombre de primitives système. Celle-ci permettent principalement de gérer les processus s'exécutant sur la machine (kill, waitpid, ...). Il faut donc créer une structure adaptée pour les processus afin les manipuler le plus simplement possible.

La gestion des privilèges est une opération bien plus complexes que les précédentes. Il s'agit ici de découper notre système en 2 modes:

  • le mode Kernel (celui utilisé jusqu'à présent), où il est possible d'accéder à n'importe quel endroit de la mémoire
  • le mode User, où l'accès a l'espace mémoire du kernel est interdit.

L'utilité de cette gestion de privilèges est de protéger notre noyau des applications buggées ou malveillantes.

Techniquement, cette gestion de privilèges se traduit par l'utilisation de 2 piles par processus, des registres de segments et d'une interruption logiciel. La difficulté est de bien initialiser la pile kernel au lancement d'un processus, en n'oubliant pas ce qu'il faut pour simuler un retour d'interruption.

Une fois cette séparation effectuée, il faut quand même pouvoir lancer les primitives systèmes (définies en kernel) depuis le mode user. Pour ce faire, nous allons utiliser les interruption logicielles pour passer en mode kernel et utiliser les registres pour le passage de paramètre (Attention de bien initialiser les traitants d’interruption avec les bons droits!).

La dernière étape consiste à insérer un shell dans notre système. Il faut pour cela coder le traitement du clavier qui revient à utiliser un buffer sur le modèle producteur/consommateur avec un sémaphore. Nous avons étendu notre shell en ajoutant de nouvelles primitives systèmes à celles définies dans le cahier des charges.

Voici les commandes qui peuvent être lancées depuis notre shell:

Commande Description

about

Affiche la bannière de l'OS

exit

Permet de quitter le shell.

ps

Affiche les processus en cours d’exécution sur la machine.

clear

Nettoie l'écran.

t

Lance les tests fournis.

nos_tests

Lance nos tests sur le système.

sinfo

Information sur les semaphores.

ssouris [1-8]

Change la sensibilité de la souris , valeur[1,8] 1= très sensible 8= le moins sensible.

echo [on|off]

Active/Désactive l'affichage direct des cratères tapés au clavier.

matrix

Remplis l’écran de caractères.

sb16

Joue la musique "Ocean Avenue" de "Yellowcard".

demo

Lance le jeu de dextérité.

Extensions

Driver Carte Son Sound Blaster16

Nous avons choisi cette extension car la carte son est un dispositif très intéressant que nous connaissions peu. Nous voulions apprendre de quelle façon marche une carte son et comment développer un pilote de périphérique. Nous avons choisi la carte son Sound Blaster 16 de Creative parce qu'elle est disponible sur VirtualBox mais aussi parce qu'il est facile de trouver de la documentation sur la carte.

Le mode de fonctionnement de la carte est très simple. Nous avons principalment deux dispositifs qui font marcher la carte son: DMA (Direct memory access) et le DSP (Digital signal processor). Le premier nous permet d'écrire dans la mémoire de la machine sans l'intervention du microprocesseur. Le deuxième nous permet le traitement numérique du signal (dans notre cas, le son). Notre pilote prend en charge le mode Single cycle, ça veut dire qu'à chaque fois que l'on veut produire un son, nous devons réinitialiser le DMA et le DSP et lui dire qu l'on envoie un nouveau paquet de taille T. Avec l'aide du DMA, on ecrit le paquet dans un espace memoire réservé qui va être lut par le DSP. Quand le DSP finit la lecture ce paquet, il lance une interruption. On envoi alors les paquets restants jusqu'à ce que toute la piste son soit lue.

Comme il nous manque le support des fichiers, nous avons utilisé (et adapté pour nos besoins) le programme fait par un équipe du Projet système de l'année 2010 qui converti un fichier .wav en un tableau de données brutes dans un fichier C.


Driver Souris

Pour développer le driver de la souris nous nous sommes appuyés principalement sur la documentation de OSdev.

Nous avons choisi cet fonctionnalité afin que notre système supporte les périphériques dont nous avons l'habitue d'utiliser. Au niveau technique, implémenter ce driver était simple mais nous demande de connaitre d'autres concepts sur les PICs, qui gèrent les interruptions matériels.

La souris n'est pas en mode graphique puisque nous n'avons pas implémenté la carte graphique. On se contente de l'afficher sous la forme d'un curseur à la bonne position sur l'écran.

Nous avons aussi implanté un gestionnaire de sensibilité de la souris. Celle-ci est réglable sur une échelle de 1 à 8. Cette modification de sensibilité s'effectue via une commande du shell listée au dessus.


Mémoire Virtuelle

Mécanisme de translation d'adresse

La mémoire virtuelle permet de cloîtrer chaque processus dans un espace mémoire virtuelle qui lui est propre. Le processus croit qu'il dispose de 4Go de mémoire pour lui seul (Notre système utilise en tout 48Mo de mémoire physique).

Pour arriver à mettre en place cette mémoire virtuelle, il faut réaliser un allocateur de pages dans la partie user de la mémoire physique. Nous avons fait le choix de ne jamais allouer de pages dans la mémoire kernel. Cet allocateur sera utilisé lorsque l'on a besoin de mémoire pour stocker le code, la pile mais aussi les tables des pages de l'application. Ces dernières sont utilisées pour assurer la translation entre adresses virtuelle/physique.

Nous avons réaliser le mappage suivant:

  1. Mémoire virtuelle
    • 0-1Go : espace kernel. Ces adresses sont patagées entre tous les processus
      • 0-48Mo : mappage virtuelle = physique. Le kernel accède a toute la mémoire sans effectuer de translation (beaucoup plus facile pour la modification des tables des pages)
    • 1Go-4Go : espace user.
      • 1Go-3Go : le code de l'application est mappé sur ces adresses.
      • 3Go-4Go : espace réservée pour la pile de l'application
  2. Memoire physique
    • 0-16Mo : espace kernel
    • 16Mo-48Mo : espace user

Comme vous l'avez remarquer, nous n'avons pas géré de tas en mémoire virtuelle. il n'est pas possible d'allouer dynamiquement de la mémoire pour l'instant. Nous n'avons pas non plus codé la libération de la mémoire. En effet, la virtualisation implique un partage de certaines pages. Il faut donc avoir un compteur de références sur les pages pour empêcher la désallocation de ces pages partagées.

Cette phase implique de grosses modification dans le corps de votre programme (notamment pour la chaine de compilation). Si vous voulez réaliser cette extension sur votre projet et que vous travailler à plusieurs grâce à un gestionnaire de version, penser à faire une branche.

Remarque : Nous avons encore un problème pour le passage des arguments lors de la création d'un processus.


Extension RTC

Pour finir, nous avons développé un pilote pour accéder au Real Time Clock (RTC) dans le chip CMOS. Nous avons réussi l'activation de l'IRQ8 permettant de récupérer les données de cette horloge, mais les valeurs lues étaient incohérentes. De plus, lors de nos tests sur machine réelle, nous nous sommes aperçu que nous déréglons cette horloge et que le BIOS nous demandait de la reconfigurer après chaque démarrage de la machine. Nous avons donc fait le choix de ne pas l'intégré dans notre rendu finale pour ne pas causer ces problèmes aux personnes qui souhaitent utiliser notre OS.

Références

Développement d'un OS

TutoOS Copyright (C) 2008, Arnauld Michelizza. Site expliquant le développement d'un OS pas à pas. Vraiment TRÈS utile.

OSdev Wiki

Doc de l'Intel

Driver Carte Son

Manuel par Creative Labs et autres ressources

Idée générale de comment le faire

Exemple complet en C++

Sound Blaster 16 en Minix

Driver Souris

Doc_OsDev_mouse

Code_Mouse

Erreurs 'IRQ2'

InfoPS2

mapping des PICs

Environnement de travail

Outils techniques

Mercurial, un gestionnaire de version distribué.

VirtualBox, machine virtuelles.

vim et gvim , des éditeurs de texte.

gcc , le compilateur de c sur Linux.

gdb, ddd & Nemiver, des debugger.

Outils de gestion de projet

Planner , planification des tâches et modèle de Gantt

gedit, editeur de texte pour journal de bord

Paroles de l’équipe

ON peut résumer ce projet en une seule mot: ÉMOUVANT =D (dédicace à P. Bodiglio)