Projet système : Différence entre versions

De Ensiwiki
Aller à : navigation, rechercher
(Aide générale)
(débogage du noyau: utiliser l'écran bleu)
 
(25 révisions intermédiaires par 5 utilisateurs non affichées)
Ligne 7 : Ligne 7 :
 
= Présentation =
 
= 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 :
+
L'objectif du projet système est la réalisation d'un noyau de système d'exploitation sur une architecture Intel x86 et, pour la première fois en 2019, le risc-v 64 bits. 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 ;
 
* la création et l'exécution des processus ;
Ligne 16 : Ligne 16 :
  
 
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.
 
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.
 +
Seuls les élèves les plus téméraires de PCSEA peuvent choisir la version risc-v, qui essuie les plâtres en 2019.
  
 
= Breaking news! =
 
= Breaking news! =
Ligne 23 : Ligne 24 :
 
Makefile fourni :  
 
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.
 
* 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é)
+
* Pour compiler avec gcc-6 et plus (gcc-7, 8, 9, ...) 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 \
 
   CFLAGS := -m32 \
 
     -Wall -Wextra -Werror -std=c99 \
 
     -Wall -Wextra -Werror -std=c99 \
Ligne 49 : Ligne 50 :
 
}}
 
}}
  
== ctags ==
+
== débogage du noyau: utiliser l'écran bleu ==
 +
 
 +
Par les choses les plus utiles, la valeur de EIP indique l'instruction ayant provoqué l'erreur. Pour voir à quelle fonction cela correspond et pourquoi, vous pouvez désassembler le noyau.
 +
<code>
 +
objdump -D kernel.bin | less
 +
</code>
 +
et faire une recherche avec <code>/</code>
 +
 
 +
ou bien rediriger la sortie vers un fichier, le lire avec votre éditeur préféré et '''bien penser à le supprimer, sinon, il sera compilé dans votre noyau''' !!!
 +
<code>
 +
objdump -D kernel.bin > kernel.s && emacs kernel.s --eval="(asm-mode)" --eval="(read-only-mode)" && rm kernel.s
 +
</code>
 +
 
 +
== débogage du noyau: automatiser votre workflow ==
 +
 
 +
Ajouter dans votre makefile de quoi déboguer semi-automatiquement.
 +
debug:
 +
        qemu-system-i386 -s -S -m 256M -kernel kernel.bin &
 +
        emacs --eval '(setq gdb-many-windows t)' --eval '(gdb "gdb -i=mi kernel.bin")' --eval '(insert "target remote :12345")' --eval '(gdb-frame-disassembly-buffer)'
 +
 
 +
== ctags et vim ==
 
Pour les amateurs qui se lassent de naviguer entre leurs fichiers à l'aveuglette, il y a une version de <code>ctags</code> disponible dans <code>~petrot/Public/bin</code> qui comprend aussi l'assembleur, bien pratique pour explorer le boot, le changement de contexte, etc!
 
Pour les amateurs qui se lassent de naviguer entre leurs fichiers à l'aveuglette, il y a une version de <code>ctags</code> disponible dans <code>~petrot/Public/bin</code> qui comprend aussi l'assembleur, bien pratique pour explorer le boot, le changement de contexte, etc!
  
Ligne 58 : Ligne 79 :
 
Ceci devrait créer un fichier <code>tags</code> localement. Ensuite, si vous éditez de ce répertoire (avec vi, cela va sans dire), par ex. <code>vim kernel/boot/boot.c</code>, alors le fichier sera directement pris en compte. Sinon, il faut faire un <code>:se tags=../../tags</code> si vous êtes dans le répertoire <code>boot</code> pour l'exemple précédent. Pour aller à la définition d'une fonction <code>Ctrl-]</code>, pour revenir là ou elle était utilisée <code>Ctrl-T</code>. Voila pour l'utilisation basique, sinon <code>:help tags</code> sous vi vous donne accès à 837 lignes d'explications plus détaillées.
 
Ceci devrait créer un fichier <code>tags</code> localement. Ensuite, si vous éditez de ce répertoire (avec vi, cela va sans dire), par ex. <code>vim kernel/boot/boot.c</code>, alors le fichier sera directement pris en compte. Sinon, il faut faire un <code>:se tags=../../tags</code> si vous êtes dans le répertoire <code>boot</code> pour l'exemple précédent. Pour aller à la définition d'une fonction <code>Ctrl-]</code>, pour revenir là ou elle était utilisée <code>Ctrl-T</code>. Voila pour l'utilisation basique, sinon <code>:help tags</code> sous vi vous donne accès à 837 lignes d'explications plus détaillées.
  
 +
== etags et emacs ==
 +
etags est l'équivalent de ctags, pour emacs. Il s'utilise de la même façon. Il crée un fichier TAGS. <code>M-.</code> pour trouver la définition. <code>M-,</code> pour revenir au point de départ de la recherche.
 +
 +
== gnu global, avec vim, emacs, less, bash, doxygen  ==
 +
Gtags, du paquet GNU Global, qui comprend lui aussi C et l'assembleur. Ce dernier permet de trouver les définitions mais aussi les références.
 +
Il explore tous les sous-répertoires du répertoire de départ. Dans la racine de votre projet, il suffit donc de faire <code>gtags .</code>
 +
Il faudra voir
 +
 +
== projectile et emacs ==
 +
Le greffon projectile permet à emacs de manipuler tous les fichiers d'un projet (git, maven, etc.): grep, occur, remplacement, etc. Il peut utiliser aussi les fichiers etags/gtags . Il est disponible dans le paquet Debian/Ubuntu elpa-projectile  pour une installation globale ou, pour une installation locale, en faisant <code>M-x package-install RET projectile RET</code> dans votre emacs.
 +
 +
== Semantic et emacs ==
 +
Emacs possède son propre parser qui "comprend" la syntaxe des langages (pas juste des regexp comme les outils précédents). Il s'active dans le menu <code>Tools => Source code parsers (Semantic)</code>. En le combinant avec projectile pour ouvrir dans emacs tous les fichiers de votre projet, il permet de trouver les définitions <code>C-c , J</code>, mais aussi d'avoir des détails dans la speedbar (type des références (variables, fonctions) les arguments). Pour cela il faut ajouter <code>(require 'semantic/sb)</code> dans votre .emacs.
 +
 +
Néanmoins, il ne comprend pas encore l'assembleur, ce qui en limite un peu l'usage pour ce projet.
  
 
<!--
 
<!--
Ligne 87 : Ligne 123 :
 
}}
 
}}
 
{{APP_Only|texte_app=
 
{{APP_Only|texte_app=
Le projet se déroule sur une période pleine, du 8 juin au 28 juin.
+
Le projet se déroule sur une période pleine, du 7 juin au 27 juin.
  
Le projet démarre le '''jeudi 8 juin 2017 à 9h00 en salle D200'''.
+
Le projet démarre le '''jeudi 7 juin 2018 à 9h00 en salle E212'''.
  
Ensuite, la salle D200 vous est réservée du jeudi 8 juin 9h00 jusqu'au mercredi 28 juin 17h00.
+
Ensuite, la salle E212 vous est réservée du jeudi 7 juin 9h00 jusqu'au mercredi 27 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.
+
Côté encadrement, il y aura trois séances encadrées la première semaine : le jeudi 7 juin de 9h à 12h (démarrage du projet), le vendredi 8 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.
+
Ensuite, sur la période du 12 au 26 juin, soit Julie Dumas, 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.
+
La journée du 27 juin sera consacrée aux soutenances.
 
}}
 
}}
  
Ligne 103 : Ligne 139 :
 
}}
 
}}
 
{{APP_Only|texte_app=
 
{{APP_Only|texte_app=
* [mailto:francois.broquedis@grenoble-inp.fr François Broquedis], [mailto:Gregory.Mounie@imag.fr Grégory Mounié]  et [mailto:Patrick.Reignier@imag.fr Patrick Reignier] pour le projet de spécialité apprentis 2A,
+
* [mailto:yves.denneulin@imag.fr Yves Denneulin], [mailto:Gregory.Mounie@imag.fr Grégory Mounié]  et [mailto:Patrick.Reignier@imag.fr Patrick Reignier] pour le projet de spécialité apprentis 2A,
 
}}
 
}}
 +
 
== Suivi ==
 
== Suivi ==
 
* Un journal de bord doit être rempli quotidiennement, par exemple sur la page wiki de votre projet.
 
* Un journal de bord doit être rempli quotidiennement, par exemple sur la page wiki de votre projet.
Ligne 162 : Ligne 199 :
  
 
== Dépôts GIT ==
 
== Dépôts GIT ==
 +
=== pour OS sur x86 ===
  
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 :
+
Les dépôts Git relatifs à la version x86 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 :  
 
Pour les 2A et pour les 2A apprentissage dans une équipe officielle :  
  
 
  2A:
 
  2A:
  git clone ssh://votre_login@depots.ensimag.fr/depots/2017/psys/login1-login2-login3-login4-login5-login6/psys-base psys.git
+
  git clone ssh://votre_login@depots.ensimag.fr/depots/2018/psys/login1-login2-login3-login4-login5-login6/psys-base psys.git
 
  2A Apprentis:
 
  2A Apprentis:
  git clone ssh://votre_login@depots.ensimag.fr/depots/2017/psysAPP/login1-login2-login3/psys-base psys.git
+
  Les sources à cloner sont dans le projet de votre équipe dans https://gitlab.ensimag.fr de la forme (cf votre page du projet)
 +
git clone git@gitlab.ensimag.fr:psysappYYYY/psysApp_LOGIN1_LOGIN2.git
 +
<!-- git clone ssh://votre_login@depots.ensimag.fr/depots/2018/psysAPP/login1-login2-login3/psys-base psys.git -->
  
  
Ligne 176 : Ligne 216 :
  
 
  2A:  
 
  2A:  
  git clone ssh://votre_login@depots.ensimag.fr/depots/2017/psys/psys-base psys.git
+
  git clone ssh://votre_login@depots.ensimag.fr/depots/2018/psys/psys-base psys.git
 
  2A Apprentis:
 
  2A Apprentis:
  git clone ssh://votre_login@depots.ensimag.fr/depots/2017/psysAPP/login1-login2-login3/psys-base psys.git
+
  Repartir de la première version de votre projet dans https://gitlab.ensimag.fr
 +
<!-- git clone ssh://votre_login@depots.ensimag.fr/depots/2018/psysAPP/psys-base psys.git -->
  
  
Ligne 199 : Ligne 240 :
  
 
Vous pouvez vous référez à la page [[Git]].
 
Vous pouvez vous référez à la page [[Git]].
 +
 +
=== pour OS sur RISC-V ===
 +
Les différents dépôts ainsi que l'information spécifique au RISC-V sont disponibles sur le [https://gitlab.ensimag.fr/pcserv groupe PCSERV '''gitlab''' de l'Ensimag].
 +
 +
Toute l'information utile est sur le [https://gitlab.ensimag.fr/pcserv/documentation-risc-v/wikis/home wiki] du projet PCSEA sous RISC-V.
  
 
== Roadmap imposée ==
 
== Roadmap imposée ==
Ligne 334 : Ligne 380 :
 
  info gdb
 
  info gdb
 
  info ddd
 
  info ddd
 +
 +
Notez qu'en x86 gdb ne sait pas afficher les registres de contrôle du processeur (les cr*). Mais QEMU vient à notre rescousse ! Lors d'une session de débug, il suffit de taper <ctrl-a>c là ou QEMU s'exécute, puis <code>info registers</code> pour afficher la valeur des registres. Vous pouvez continuer de débugger et simultanément faire cette commande dans la console QEMU pour voir l'évolution des registres.
  
 
=== Éléments d'assembleur et de C ===
 
=== Éléments d'assembleur et de C ===
Ligne 347 : Ligne 395 :
  
 
* Insérer de l'assembleur dans du C (''pratique non recommandée car beaucoup de pièges'') : <tt>info gcc</tt>, section <tt>C extensions</tt>, puis <tt>Extended Asm</tt>
 
* Insérer de l'assembleur dans du C (''pratique non recommandée car beaucoup de pièges'') : <tt>info gcc</tt>, section <tt>C extensions</tt>, puis <tt>Extended Asm</tt>
 +
 +
 +
Pour ce qui concerne le risc-v, en sus des specs user et système disponibles par ailleurs, il faut connaître [https://github.com/riscv/riscv-elf-psabi-doc/riscv-elf.md les conventions d'appel de fonctions]
  
 
=== Processeurs Intel ===
 
=== Processeurs Intel ===
Ligne 357 : Ligne 408 :
 
** [https://github.com/zneak/x86doc HTML representation of the Intel x86 instructions documentation]
 
** [https://github.com/zneak/x86doc HTML representation of the Intel x86 instructions documentation]
 
* Intel Architecture Software Developer's Manual, [http://www.intel.com/Assets/PDF/manual/253668.pdf Vol.3a: System Programming] et [http://www.intel.com/Assets/PDF/manual/253669.pdf Vol.3b: System Programming]
 
* Intel Architecture Software Developer's Manual, [http://www.intel.com/Assets/PDF/manual/253668.pdf Vol.3a: System Programming] et [http://www.intel.com/Assets/PDF/manual/253669.pdf Vol.3b: System Programming]
 +
 +
=== Processeurs RISC-V ===
 +
* [https://riscv.org/specifications/ la page avec les spécifications de l'ISA utilisateur du RISC-V] Cette page regroupe toutes les instructions de base du processeur. On ne se souciera pas des instructions qui ne travaillent pas sur les registres entiers.
 +
* [https://riscv.org/specifications/privileged-isa/ les spécifications de l'ISA système] en particulier les différents registres pour la gestion des interruptions et des modes.
 +
 +
* [https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md les conventions d'appel de fonctions] afin de connaître l'usage des différents registres, et comment gérer la pile, pour les quelques lignes d'assembleur que vous aurez à écrire.
  
 
=== Développement d'OS ===
 
=== Développement d'OS ===

Version actuelle en date du 24 juin 2019 à 21:37

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 x86 et, pour la première fois en 2019, le risc-v 64 bits. 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. Seuls les élèves les plus téméraires de PCSEA peuvent choisir la version risc-v, qui essuie les plâtres en 2019.

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 plus (gcc-7, 8, 9, ...) 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.

  • Pour compiler sur toutes les machines (Ensimag et gcc-7), il faut éditer les erreurs pour ajouter autour des attributes((...)) la macro suivante:
 #if __GNUC__ > 6
                 __attribute__((fallthrough));
 #endif


PCSEA
* Dans kernel/kbd-linux/keyboard.c gcc-6 detecte deux variables inutilisées que vous pouvez commenter.

débogage du noyau: utiliser l'écran bleu

Par les choses les plus utiles, la valeur de EIP indique l'instruction ayant provoqué l'erreur. Pour voir à quelle fonction cela correspond et pourquoi, vous pouvez désassembler le noyau. objdump -D kernel.bin | less et faire une recherche avec /

ou bien rediriger la sortie vers un fichier, le lire avec votre éditeur préféré et bien penser à le supprimer, sinon, il sera compilé dans votre noyau !!! objdump -D kernel.bin > kernel.s && emacs kernel.s --eval="(asm-mode)" --eval="(read-only-mode)" && rm kernel.s

débogage du noyau: automatiser votre workflow

Ajouter dans votre makefile de quoi déboguer semi-automatiquement.

debug:
       qemu-system-i386 -s -S -m 256M -kernel kernel.bin &
       emacs --eval '(setq gdb-many-windows t)' --eval '(gdb "gdb -i=mi kernel.bin")' --eval '(insert "target remote :12345")' --eval '(gdb-frame-disassembly-buffer)'

ctags et vim

Pour les amateurs qui se lassent de naviguer entre leurs fichiers à l'aveuglette, il y a une version de ctags disponible dans ~petrot/Public/bin qui comprend aussi l'assembleur, bien pratique pour explorer le boot, le changement de contexte, etc!

Pour créer votre base de tags (à refaire si vous ajoutez vos propres fonctions bien sur), allez dans psys-base, puis : find . -name \*.[chSs] | xargs ctags Ceci devrait créer un fichier tags localement. Ensuite, si vous éditez de ce répertoire (avec vi, cela va sans dire), par ex. vim kernel/boot/boot.c, alors le fichier sera directement pris en compte. Sinon, il faut faire un :se tags=../../tags si vous êtes dans le répertoire boot pour l'exemple précédent. Pour aller à la définition d'une fonction Ctrl-], pour revenir là ou elle était utilisée Ctrl-T. Voila pour l'utilisation basique, sinon :help tags sous vi vous donne accès à 837 lignes d'explications plus détaillées.

etags et emacs

etags est l'équivalent de ctags, pour emacs. Il s'utilise de la même façon. Il crée un fichier TAGS. M-. pour trouver la définition. M-, pour revenir au point de départ de la recherche.

gnu global, avec vim, emacs, less, bash, doxygen

Gtags, du paquet GNU Global, qui comprend lui aussi C et l'assembleur. Ce dernier permet de trouver les définitions mais aussi les références. Il explore tous les sous-répertoires du répertoire de départ. Dans la racine de votre projet, il suffit donc de faire gtags . Il faudra voir

projectile et emacs

Le greffon projectile permet à emacs de manipuler tous les fichiers d'un projet (git, maven, etc.): grep, occur, remplacement, etc. Il peut utiliser aussi les fichiers etags/gtags . Il est disponible dans le paquet Debian/Ubuntu elpa-projectile pour une installation globale ou, pour une installation locale, en faisant M-x package-install RET projectile RET dans votre emacs.

Semantic et emacs

Emacs possède son propre parser qui "comprend" la syntaxe des langages (pas juste des regexp comme les outils précédents). Il s'active dans le menu Tools => Source code parsers (Semantic). En le combinant avec projectile pour ouvrir dans emacs tous les fichiers de votre projet, il permet de trouver les définitions C-c , J, mais aussi d'avoir des détails dans la speedbar (type des références (variables, fonctions) les arguments). Pour cela il faut ajouter (require 'semantic/sb) dans votre .emacs.

Néanmoins, il ne comprend pas encore l'assembleur, ce qui en limite un peu l'usage pour ce projet.


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 7 juin au 27 juin.

Le projet démarre le jeudi 7 juin 2018 à 9h00 en salle E212.

Ensuite, la salle E212 vous est réservée du jeudi 7 juin 9h00 jusqu'au mercredi 27 juin 17h00.

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

La journée du 27 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
* Yves Denneulin, 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.
Page sur ensiwiki
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.
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

pour OS sur x86

Les dépôts Git relatifs à la version x86 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/2018/psys/login1-login2-login3-login4-login5-login6/psys-base psys.git
2A Apprentis:
Les sources à cloner sont dans le projet de votre équipe dans https://gitlab.ensimag.fr de la forme (cf votre page du projet)
git clone git@gitlab.ensimag.fr:psysappYYYY/psysApp_LOGIN1_LOGIN2.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/2018/psys/psys-base psys.git
2A Apprentis:
Repartir de la première version de votre projet dans https://gitlab.ensimag.fr


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.

pour OS sur RISC-V

Les différents dépôts ainsi que l'information spécifique au RISC-V sont disponibles sur le groupe PCSERV gitlab de l'Ensimag.

Toute l'information utile est sur le wiki du projet PCSEA sous RISC-V.

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 à plusieurs. 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

Notez qu'en x86 gdb ne sait pas afficher les registres de contrôle du processeur (les cr*). Mais QEMU vient à notre rescousse ! Lors d'une session de débug, il suffit de taper <ctrl-a>c là ou QEMU s'exécute, puis info registers pour afficher la valeur des registres. Vous pouvez continuer de débugger et simultanément faire cette commande dans la console QEMU pour voir l'évolution des registres.

É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


Pour ce qui concerne le risc-v, en sus des specs user et système disponibles par ailleurs, il faut connaître les conventions d'appel de fonctions

Processeurs Intel

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

Processeurs RISC-V

  • les conventions d'appel de fonctions afin de connaître l'usage des différents registres, et comment gérer la pile, pour les quelques lignes d'assembleur que vous aurez à écrire.

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