Projet système

De Ensiwiki
Révision de 16 juin 2017 à 09:03 par Mounieg (discussion | contributions) (Breaking news!)

Aller à : navigation, rechercher
AttentionCette page est maintenue uniquement par les enseignants. Afin de ne pas perturber le déroulement des cours, elle n'a pas vocation à être modifiée par les élèves. Mais si vous avez des modifications à proposer, merci d'en discuter ou d'envoyer un e-mail aux auteurs de la page (cf. historique)

Mycomputer.png  Deuxième Année  CDROM.png  Informatique 

Présentation

L'objectif du projet système est la réalisation d'un noyau de système d'exploitation sur une architecture Intel. En pratique, en partant de rien (ou presque), vous allez devoir mettre en oeuvre un certain nombre de concepts clés associés aux systèmes d'exploitation, comme par exemple :

  • la création et l'exécution des processus ;
  • leur synchronisation ;
  • leur ordonnancement ;
  • la gestion des entrées/sorties (clavier, écran) ;
  • l'implémentation d'un interprète de commandes.

Le projet système se décline en deux versions, l'une destinée aux élèves de 2A suivant le projet de spécialité "Projet de Conception d'un Système d'Exploitation : Approfondissement" (PCSEA), l'autre destinée aux élèves Ensimag apprentis 2e année.

Breaking news!

Cette section sera mise à jour en cours de projet, elle permet de communiquer sur des points particuliers d'organisation ou d'éventuels corrections de bugs dans les ressources fournies (à la fois doc + code).

Makefile fourni :

  • Si vous travaillez sur votre machine personnelle avec gcc-6, il faut ajouter -march=pentium dans les options passées à gcc pour ne pas avoir de soucis.
  • Pour compiler avec gcc-6 et 7 vous devez désactiver l'option PIE dans le Makefile du kernel (les variables sont placées aléatoirement en mémoire, pour des raisons de sécurité)
  CFLAGS := -m32 \
  		  -Wall -Wextra -Werror -std=c99 \
  		  -g -gstabs \
  		  -pipe \
  		  -nostdinc \
  		  -nostdlib \
  		  -fno-stack-protector \
  		  -fno-pie -no-pie \ //  <--------- ici
  		  $(DEFS)
  
  LDFLAGS := -g -melf_i386 -no-pie // <---- et là
  • Dans l'option CFLAGS du kernel/Makefile
  -gstabs

semble provoquer un décalage dans la compréhension des adresses des variables par gdb. Vous pouvez supprimer cette option si besoin.

PCSEA
* Dans kernel/kbd-linux/keyboard.c gcc-6 detecte deux variables inutilisées que vous pouvez commenter.
Apprentis
Projet pour les apprentis :

Top départ le jeudi 8 juin 2017 à 9h00 en D200!

Présentation

Ajouter /usr/libexec à votre PATH (faites le une fois pour toute dans le .bash_rc par exemple).

Consignes et partie administrative

Planning d'encadrement

PCSEA
Le projet se déroule sur 11 semaines. Deux séances encadrées de 1h30 chaque semaine.
Apprentis
Le projet se déroule sur une période pleine, du 8 juin au 28 juin.

Le projet démarre le jeudi 8 juin 2017 à 9h00 en salle D200.

Ensuite, la salle D200 vous est réservée du jeudi 8 juin 9h00 jusqu'au mercredi 28 juin 17h00.

Côté encadrement, il y aura trois séances encadrées la première semaine : le jeudi 8 juin de 9h à 12h (démarrage du projet), le vendredi 9 juin de 9h à 12h et de 14h à 17h. Ensuite, sur la période du 12 au 26 juin, soit François Broquedis, soit Patrick Reignier, soit Grégory Mounié sera présent les lundi, mercredi et vendredi matin de 9h à 12h.

La journée du 28 juin sera consacrée aux soutenances.

Enseignants

PCSEA
* Grégory Mounié et Frédéric Pétrot pour le cours Projet de Conception de Système - Approfondissement (PCSEA)
Apprentis
* François Broquedis, Grégory Mounié et Patrick Reignier pour le projet de spécialité apprentis 2A,

Suivi

  • Un journal de bord doit être rempli quotidiennement, par exemple sur la page wiki de votre projet.
  • Un jeu de test est fourni pour valider partiellement les fonctionnalités du projet.

Matériel fourni au démarrage du projet

  • Un spécification technique initiale est fournie au départ (à compléter au niveau des extensions),
  • Les étapes de progression pour atteindre l'objectif minimal.

Attentes à la fin du projet

PCSEA
Pour chaque équipe, nous attendons les éléments suivants.
Livrables 
Un code clair et commenté et un dépôt bien renseigné des évolutions faites pendant tout le projet (outil git).

Note : la tenue de votre dépôt Git sera évaluée, notamment en ce qui concerne les messages de commits. Référez-vous à la section ci-dessous pour plus d'information.

Soutenance 
Une présentation de la réalisation. Il est important de montrer ce qui fonctionne et ce qui ne fonctionne pas. Les enseignants ont à leur disposition une fiche de soutenance où sont passés en revue les points critiques du projet.
Apprentis
Pour chaque équipe, nous attendons les éléments suivants.
Livrables 
Le journal de bord, un code clair et commenté et un dépôt bien renseigné des évolutions faites pendant tout le projet (outil git).

Note : la tenue de votre dépôt Git sera évaluée, notamment en ce qui concerne les messages de commits. Référez-vous à la section ci-dessous pour plus d'information.

Soutenance 
Une présentation de la réalisation. Il est important de montrer ce qui fonctionne et ce qui ne fonctionne pas. Les enseignants ont à leur disposition une fiche de soutenance où sont passés en revue les points critiques du projet.
Page web 
Une page web succincte dans le wiki (qui sera publique)
  • accessible à tout le monde, non spécialiste en système, c'est la "vitrine" de votre projet en quelque sorte ;
  • présentant ce qui a été fait : en particulier le complément aux spécifications initiales avec les extensions (appels système et fonctionnalités supplémentaires) et les plannings prévisionnel et effectif;
  • mettant l'accent sur les apports et les difficultés rencontrées ;
  • sans le code source ;
  • créée dans le wiki à partir de la page des résultats du projet système
  • référençant les sources externes (comme la documentation et le code libre utilisé, vérifiez bien les conditions liées à la licence, très important !) ;
et éventuellement
  • présentant des captures d'écran / vidéos de démos intéressantes ;
  • mettant à disposition le binaire du noyau pour pouvoir le tester dans un émulateur.
Il peut être utile de relire les consignes sur la réalisation d'une page Web.


Conception d'un système d'exploitation : ressources du projet

Dépôts GIT

Les dépôts Git sont hébergés sur depots.ensimag.fr. Ils ont été initialisés avec les sources de départ du projet. Pour en récupérer une copie, utilisez l'une des deux commandes suivantes selon l'architecture sur laquelle vous travaillez :

Pour les 2A et pour les 2A apprentissage dans une équipe officielle :

2A:
git clone ssh://votre_login@depots.ensimag.fr/depots/2016/psys/login1-login2-login3-login4-login5-login6/psys-base psys.git
2A Apprentis:
git clone ssh://votre_login@depots.ensimag.fr/depots/2016/psysAPP/login1-login2-login3/psys-base psys.git


Pour récupérer les points de départs pour un autre usage (nécessite d'avoir un compte sur depots.ensimag.fr) :

2A: 
git clone ssh://votre_login@depots.ensimag.fr/depots/2016/psys/psys-base psys.git
2A Apprentis:
git clone ssh://votre_login@depots.ensimag.fr/depots/2016/psysAPP/login1-login2-login3/psys-base psys.git


Cela créera un répertoire de travail nommé psys.git. Évidemment, il faut remplacer les mots votre_login, login1, login2 et login3 (le cas échéant) par les valeurs pertinentes. Les logins de votre équipe sont triés par ordre alphabétique.

PC
Pour intégrer votre TP de PSE, nous vous conseillons de copier un par un les fichiers pertinents. Il faut utiliser la commande git add pour qu'ils soient pris en compte par Git. Certains correctifs de la FAQ (et d'autres) ont été intégrés par rapport à la version distribuée en PSE. De plus, le répertoire user a été ajouté pour l'étape d'implantation du mode utilisateur. Le démarrage de votre noyau ainsi que son initialisation ont été changés pour faciliter l'implantation de la mémoire virtuelle


Vous pouvez vous référez à la page Git.

Roadmap imposée

Le développement du projet est découpé en 7 phases. La phase i doit être testée intensivement avant de passer à la phase i+1.

  • Phase 1 : Prise en main de l'environnement
  • Phase 2 : Création et lancement de processus de niveau noyau
  • Phase 3 : Ordonnancement, création dynamique et terminaison de processus de niveau noyau
  • Phase 4 : Gestion des communications et synchronisation de processus de niveau noyau
  • Phase 5 : Séparation des espaces mémoire noyau et utilisateur : gestion de processus utilisateur
PCSEA
+ gestion de la mémoire virtuelle (PCSEA seulement)
  • Phase 6 : Gestion du clavier et implémentation d'un pilote de console
  • Phase 7 : Implémentation d'un interprète de commandes

Les différentes phases sont détaillées sur la page : Projet système : roadmap

Extensions

Les extensions possibles sont :

  • la mise en œuvre de la mémoire virtuelle (pour les apprentis),
  • l'exploitation de périphériques complexes (carte graphique, carte son, carte réseau, ...),
  • l'exploitation de plusieurs processeurs dans le système d'exploitation.

Attention : Veillez à ne pas vous éparpiller sur deux ou trois extensions à la fois, même en trinome. Une ou deux personnes à temps plein ne sont pas de trop pour éplucher, comprendre une documentation et le matériel associé. Une extension à peine exploitée ne vaut pas grand chose.

Les extensions seront à définir au début du projet avec l'encadrant selon le goût des groupes.

Apprentis
Le complément au cahier des charges initial est à rendre en fin de projet.

Spécifications

Nous fournissons les spécifications du projet sur la page : Projet système : spécifications. Toute extension de ces spécifications devra être reportée sur votre page web de suivi de projet.

Résultats des projets passés

Les pages demandées ci-dessus sont regroupées dans les résultats du projet système.

Documentation du projet

Toutes les ressources suivantes sont en lien direct avec le projet.

Aide générale

Focus sur certaines parties spécifiques


Documentation annexe

gdb et ddd

  • Tout la documentation est accessible par les commandes :
info gdb
info ddd

Éléments d'assembleur et de C

  • Insérer de l'assembleur dans du C (pratique non recommandée car beaucoup de pièges) : info gcc, section C extensions, puis Extended Asm

Processeurs Intel

Attention: ne pas imprimer ces documents (plus de 500 pages chacun)

Développement d'OS

  • Art of Assembly (l'édition DOS 16 bit contient des informations sur la programmation des drivers)

Gestion du dépôt GIT

Maintenir un dépôt pour développer dans de bonnes conditions nécessite un peu de rigueur. Il existe quelques règles de bon sens à respecter pour que le projet se déroule dans de bonnes conditions pour tous les membres du groupe:

  • Commiter régulièrement : c'est sauvegarder son code, et se faciliter la vie grace aux outils de Git. On peut aisement tester, revenir en arrière. N'hésitez pas à créer plusieurs commits, quitte à les squasher ensuite pour n'avoir qu'un commit fonctionnel.
  • Maitriser la taille d'un commit : un commit, c'est une fonctionnalité ou une correction de bug. Dans l'idéal un commit doit être de taille raisonnable (pas 25 fichiers d'un coup, et pas 10000 lignes de codes en plus) et se restreindre à un modifier un nombre de fichiers réduits, sauf exception. On doit pouvoir l'appliquer sur des branches ou le reverter facilement sans impacter les 3/4 du code.
  • Formater son message de commit : le message de commit est d'une importance capitale. C'est la première documentation disponible à une personne qui clone votre dépôt. Il doit synthétiser la fonctionnalité ou le bug que vous corrigez, et comment vous le corrigez. Un simple git show vous montre donc le patch, et sa documentation !

Evaluation : Votre dépôt Git représente votre travail, sa tenue sera donc évaluée. Tout le monde doit contribuer au code, les informations d'auteurs doivent être correctement renseignées et les messages de commit proprement formatés.

Formater son message de commit

Le message de commit est la première documentation disponique à un collègue ou un prof qui clone votre dépôt. Concrètement, un git show montre le message de commit et le patch associé, le premier doit aider à comprendre le second dans les grandes lignes.


Ce message doit décrire la motivation du patch (le fonctionnalité proposée ou le bug corrigé) ainsi que l'implémentation que le patch fourni. A titre d'exemple, voici un des patchs fourni pour corriger un bug de la chaine de compilation du projet:

commit 9ef02d5c8b05e15f65fa2b63f623a725e07db148
Author: Damien Dejean <dam.dejean@gmail.com>
Date:   Fri May 24 20:45:55 2013 +0200

    Build: fix dependency file generation.
    
    To let make track dependencies between implementation files (.c, .S) and header
    files (.h), the toolchain generates dependency files (.d) using a gcc feature
    that creates the appropriate makefile targets. These files were listed, but not
    included, therefore not generated.
    
    This fix includes the .d files in the makefile to trig their generation and use
    them. Now make will know that it has to re-compile a c files when the included
    headers have been modified.

La première étape pour avoir des messages de commits corrects est de configurer son Git correctement, définissez un nom d'utilisateur ainsi qu'une adresse e-mail qui apparaitra dans les messages. Ne mettez pas n'importe quoi ! Souvenez-vous que dans le cas de contributions publiques (typiquement sur GitHub) les messages de commits seront votre vitrine.

Configurer son nom et son email (dans votre dépôt Git):

$ git config user.name "Damien Dejean"
$ git config user.email dam.dejean@gmail.com
$ git config -l
[...]
user.name=Damien Dejean
user.email=dam.dejean@gmail.com
[...]

Si vous souhaitez que cette configuration soit globale à votre machine, ajoutez le switch --global et tous vos dépôts hériterons de cette configuration par défaut.

Afin de vous familiariser avec les bonnes pratiques, nous vous proposons un template de commit. C'est un exemple de message qui apparaitra dans votre éditeur préféré (en tout cas celui de votre variable EDITOR) chaque fois que vous tapez git commit, pour vous guider dans votre rédaction

commit-template.txt

<"sujet: bref résumé" (60 cars max) ici !>

<La description de votre commit ici sur plusieurs lignes
 si vous le souhaitez (80 cars par ligne max)!>

Vous pouvez le définir comme template par défaut en faisant:

git config commit.template /chemin/vers/le/fichier/git-commit-template.txt