Projet système : Différence entre versions

De Ensiwiki
Aller à : navigation, rechercher
(Etudiants sans équipes, inscrivez vous ici)
(Etudiants sans équipes, inscrivez vous ici)
Ligne 10 : Ligne 10 :
  
 
'''Hugues de Valon''' (SLE) : hugues.de-valon@phelma.grenoble-inp.fr
 
'''Hugues de Valon''' (SLE) : hugues.de-valon@phelma.grenoble-inp.fr
 +
 
'''Maxime Méloux''' (MMIS) : maxime.meloux@ensimag.grenoble-inp.fr
 
'''Maxime Méloux''' (MMIS) : maxime.meloux@ensimag.grenoble-inp.fr
  

Version du 29 avril 2016 à 09:12

AttentionCette page est maintenue par les enseignants et utilisée par les élèves de la matière concernée. Vos contributions sont les bienvenues, mais merci d'en discuter avant de faire des modifications non triviales de la page, pour être sûr de ne pas perturber le déroulement du cours.

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

Etudiants sans équipes, inscrivez vous ici

Si vous êtes intéressés par le projet et que vous n'avez pas encore trouvé d'équipe pour former un trinôme pour le projet système, inscrivez votre nom ici en modifiant le wiki. Revenez régulièrement sur cette page et si d'autres sont dans votre cas, vous pourrez alors constituer une équipe via teide, et enlever vos noms de cette page.

Hugues de Valon (SLE) : hugues.de-valon@phelma.grenoble-inp.fr

Maxime Méloux (MMIS) : maxime.meloux@ensimag.grenoble-inp.fr

Actualités

Vous êtes à la recherche d'un projet :

  • qui vous permet de comprendre en détail les mécanismes des systèmes d'exploitation.
  • qui vous permet de construire vous même une brique logicielle indispensable et omniprésente dans la plupart des objets numériques.

Vous êtes au bon endroit. Bonne lecture !!!

Enseignants

François Broquedis pour le projet de spécialité 2A, Gaëtan Harter pour le projet de spécialité 2A, Frédéric Pétrot pour le projet de spécialité 2A, Grégory Mounié, Sébastien Viardot

Présentation

Les projets de spécialité système permettent de mettre en oeuvre des concepts associés aux systèmes d'exploitation : synchronisation, concurrence, partage de tâche, temps réel, pilotes matériels, ...  : voir Présentation

Pour les apprentis 2A le projet est centré sur la conception d'un système d'exploitation sur machine nue : Présentation

Catégorie conception d'un système d'exploitation

Un cahier des charges minimal est à réaliser (voir Documentation du projet). Les extensions seront à définir au début du projet avec l'encadrant selon le goût des groupes. La plateforme pour laquelle le système est développé est un PC.

Projet sur PC

PC
L'objectif est d'exploiter un PC classique et d'en écrire le système d'exploitation.

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.


Suivi

Accompagnement des étudiants

  • Autant que possible l'équipe encadrante fait en sorte qu'il y ait la présence d'un enseignant 4 1/2 journée par semaine dans la salle où se fait le projet.
  • Un journal de bord doit être rempli quotidiennement.
  • A la fin du projet un jeu de test est fourni pour valider partiellement les fonctionnalités du projet.

Les consignes transmises au départ

  • 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.

Attente à la fin du projet

Pour chaque équipe, nous attendons les éléments suivants.

Livrables 
Le cahier des charges complété avec les extensions, les plannings prévisionnel et effectif, 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, notament 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 ;
  • 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
et éventuellement
  • documentant les extensions réalisées ;
  • référençant les sources externes (comme le code libre utilisé, vérifiez bien les conditions liées à la licence, très important !) ;
  • 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.

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

PC


Documentation externe

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)

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/2014/psys/login1-login2-login3/psys-base psys.git
2A Apprentis:
git clone ssh://votre_login@depots.ensimag.fr/depots/2014/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/2014/psys/psys-base psys.git
2A Apprentis:
git clone ssh://votre_login@depots.ensimag.fr/depots/2014/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.

Gestion du dépôt

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