Changes between Version 4 and Version 5 of Archi-1-TP10

Timestamp:

Dec 20, 2020, 6:20:24 PM (4 years ago)

Author:

franck

Comment:

--

Archi-1-TP10

@@ -1 @@
-||[wiki:description_dernieres_seances retour au descriptif des séances "système"]||
+{{{#!protected
+**[https://www-soc.lip6.fr/trac/archi-l3s5/wiki/AS5-TME10-tmp?action=edit EDIT]**
+}}}
 [[PageOutline]]
-= Application simple en mode utilisateur
-
-Les applications de l'utilisateur s'exécute en mode user. Dans la séance précédente, nous avons vu que les registres de commande des contrôleurs de périphérique sont placés dans l'espace d'adressage du processeur. Et bien, les adresses de ces registres ont été choisies dans la partie de l'espace d'adressage interdite en mode user. Ainsi, une application n'a pas un accès directe aux contrôleur de périphériques, elle doit utiliser des appels système (avec l'instructions syscall) pour demander au noyau du système d'exploitation Dans cette séance, nous allons découper le code en 4 couches : (1) le code de boot (utilisé seulement au démarrage), (2) le noyau du système d'exploitation (contenant, entre autres, la fonction d'initialisation init() et le code des appels systèmes syscall), (3) la bibliothèque de fonctions standards (libc) et Dans cette séance, afin d'exécuter une application, nous allons sortir du mode kernel, utilisé par le MIPS au démarrage, pour passer en mode user. Quand le MIPS est en mode user, le code s'exécute dans un environnement restreint dans lequel il n'a pas droit à certaines instructions et il n'a pas accès à tout l'espace d'adressage. En particulier, il n'a pas accès aux adresses où ont été placés les registres de commandes des contrôleurs de périphériques. C'est dans ce mode que s'exécute les applications de l'utilisateur. Pour interagir avec les périphériques, une application doit utiliser les appels systèmes, et donc elle doit utiliser l'instruction syscall qui provoque le passage du processeur en mode kernel et l'exécution d'un code du noyau du système d'exploitation. Ce mode permet, entre autres, de garantir le bon usage des périphériques.
-
+
+
+Cette page décrit la séance complète : TD et TP. Elle commence par des exercices à faire sur papier et puis elle continue et se termine par des questions sur le code et quelques exercices de codage simples à écrire et à tester sur le prototype.
+La partie pratique  est découpée en 4 étapes. Pour chaque étape, nous donnons (1) une brève description, (2) une liste des objectifs principaux de l'étape, (3) une liste des fichiers avec un bref commentaire sur chaque fichier, (4) une liste de questions simples dont les réponses sont dans le code, le cours ou le TD et enfin (5) un exercice de codage.
+
+**IMPORTANT\\Avant de faire cette séance, vous devez avoir lu les documents suivants** :
+* [wiki:AS5-TME9 Séance de TME sur le démarrage du prototype] : ''obligatoire''
+* [htdocs:cours/AS5-10-2p.pdf Cours sur l'exécution d'une application en mode user] : ''obligatoire''
+* [htdocs:cours/doc_MIPS32.pdf Document sur l'assembleur du MIPS et la convention d'appel des fonctions] : ''recommandé''
+* [wiki:Doc-MIPS-Archi-Asm-kernel Documentation sur le mode kernel du MIPS32] : ''obligatoire''
+
+
+
+**Récupération du code du TP**
+
+
+
+* Téléchargez **[htdocs:files/tp2.tgz l'archive code du tp2]** et placez là dans le répertoire `$HOME/AS5`  
+* Assurez-vous que vous avez déjà sourcé le fichier `Source-me.sh` (sinon lisez [https://www-soc.lip6.fr/trac/archi-l3s5/wiki/Howto-TP Configuration de l'environnement des TP → Étape 3])
+* Ouvrez un `terminal`, allez dans le répertoire `AS5` (**`cd ~/AS5`**) et décompressez l'archive du tp1 avec **`tar xvzf tp2.tgz`**\\''Cette étape est peut-être inutile si vous avez déjà fait la décompression de l'archive au moment de son téléchargement.''
+* Dans le `terminal`, exécutez la commande  **`cd ; tree -L 2 AS5`**. Vous devriez obtenir ceci (tp1 et tp2):
+{{{#!bash
+AS5
+├── bin
+│   ├── almo1.x
+│   ├── gcc
+│   ├── Source-me.sh
+│   ├── test
+│   └── tracelog
+├── tp1
+│   ├── 1_hello_boot
+│   ├── 2_init_asm
+│   ├── 3_init_c
+│   ├── 4_nttys
+│   ├── 5_driver
+│   └── Makefile
+└── tp2
+    ├── 1_klibc
+    ├── 2_appk
+    ├── 3_syscalls
+    ├── 4_libc
+    └── Makefile
+}}}
+
+
+**Objectif de la séance**
+
+
+Cette séance illustre le [htdocs:cours/AS5-10-2p.pdf cours2].
+Les applications de l'utilisateur s'exécutent en mode user. Dans la séance précédente, nous avons vu que les registres de commande des contrôleurs de périphériques sont placés dans l'espace d'adressage du processeur. Les adresses de ces registres ont été placées dans la partie de l'espace d'adressage interdite en mode user. Ainsi, une application n'a pas un accès direct aux périphériques, elle doit utiliser des appels système (avec l'instruction syscall) pour demander au noyau du système d'exploitation. C'est ce que nous allons voir.
+Le code est désormais découpé en 4 couches logicielles : 
+1. `1_klibc` le code de boot (utilisé seulement au démarrage);
+2. `2_appk`  le noyau du système d'exploitation, ici pour l'essentiel, la fonction d'initialisation `kinit()` et le gestionnaire des appels systèmes;
+3. `3_syscalls` la bibliothèque de fonctions standards (libc);
+4. `4_libc` l'application.
+
+
+
+
+----
+
+= A. Travaux dirigés
+
+
+
+== A1. Les modes d'exécution du MIPS
+
+
+Dans cette section, nous allons nous intéresser à ce que propose le processeur MIPS concernant les modes d'exécution. Ce sont des questions portant sur l'usage des modes en général et le comportement du MIPS vis-à-vis de ces modes. Dans la section A3, nous verrons le code de gestion des changements de mode;
+Le MIPS propose deux modes d'exécution.
+
+
+**Questions**
+
+
+1. Le MIPS propose deux modes d'exécution, rappelez quels sont ces deux modes et à quoi ils servent? (''Nous l'avons dit dans le descriptif de la séance'').
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- Il y a le mode kernel et le mode user. 
+- Le mode kernel est utilisé par le noyau alors que le mode user est utilisé par l'application.
+'''''''''''''''
+}}} 
+1. Commencez par rappeler ce qu'est l'espace d'adressage du MIPS, puis dîtes ce que veut dire qu'une adresse X mappée en mémoire, et enfin dîtes si une adresse X mappée en mémoire est toujours accessible (en lecture ou en écriture) quelque soit le mode d'exécution du MIPS.
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- L'espace d'adressage du MIPS, c'est l'ensemble des adresses que peut produire le MIPS
+- On dit qu'une adresse est mappée en mémoire, s'il y a bien une case mémoire pour cette adresse.
+- Non X n'est pas toujours accessible, si X est < `0x80000000` elle est bien accessible quelque-soit le mode d'exécution du MIPS, mais si X >= `0x80000000` alors X n'est accessible que si le MIPS est en mode kernel.
+'''''''''''''''
+}}}
+1. Le MIPS propose des registres à usage général (GPR ''General Purpose Register'') pour les calculs ($0 à $31). Le MIPS propose un deuxième banc de registres à l'usage du système d'exploitation, ce sont les registres système. Comment sont-ils numérotés? Chaque registre porte un nom correspondant à son usage, quels sont ceux que vous connaissez, donner leur nom, leur numéro et leur rôle? Peut-on faire des calculs avec des registres? Quelles sont les instructions qui permettent de les manipuler?
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- Les registres système sont numérotés de $0 à $31, comme les registres GPR, ce qui peut induire une certaine confusion
+- Nous avons vu 6
+   || `cr_sr`     || `$12` || contient essentiellement le mode d'exécution du MIPS et le bit d'autorisation des interruptions
+   || `cr_cause`  || `$13` || contient la cause d'appel du noyau
+   || `cr_epc`    || `$14` || contient l'adresse de l'instruction ayant provoqué l'appel du noyau ou l'adresse de l'instruction suivante
+   || `cr_bar`    || `$8 ` || contient l'adresse mal formée si la cause est une exception due à un accès non aligné (p.ex. lw a une adresse non multiple de 4)
+   || `cr_count`  || `$9 ` || contient le nombre de cycles depuis le démarrage du MIPS
+   || `cr_procid` || `$15` || contient le numéro du processeur (utile pour les architectures multicores)
+- non, il n'est pas possible de faire des calculs sur ces registres.
+- On peut juste les lire et les écrire en utilisant les instructions `mtc0` et `mfc0`
+'''''''''''''''
+}}}
+1. Le registre status est composé de plusieurs champs de bits qui ont chacun une fonction spécifique. Décrivez le contenu du registre status et le rôle des bits de l'octet 0(seulement ceux vu en cours).
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+ || 0|| IE  ||Interrupt Enable||0 → interruptions masquées\\1 → interruptions autorisées
+ || 1|| EXL ||EXception Level ||1 → MIPS en mode exception\\à l'entrée dans le kernel, le MIPS est en mode kernel, interruptions masquées
+ || 2|| ERL ||ERror Level     ||0 → interruptions masquées\\1 → interruptions autorisées
+ || 4|| UM  ||User Mode       ||0 → interruptions masquées\\1 → interruptions autorisées
+'''''''''''''''
+}}}
+1. Le registre cause est contient la cause d'appel du kernel. Dites à quel endroit est stockée cette cause et donnez la signification des codes 0, 4 et 8 
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- Le champ `XCODE` qui contient le code de la cause d'entrée dans le noyau est codé sur 4 bits entre les bits 2 et 5.
+- Les valeurs les plus importantes sont:
+
+  || 0000,,b,, || interruption || un contrôleur de périphérique à lever un signal IRQ
+  || 0100,,b,, || ADEL         || lecture non-alignée (p. ex. `lw` a une adresse impaire)
+  || 1000,,b,, || syscall      || exécution de l'instruction `syscall`
+'''''''''''''''
+}}}
+1. Le registre `EPC` est un registre 32 bits qui contient une adresse. Vous devriez l'avoir décrit dans la question 2, mais expliquez pourquoi ce doit être l'adresse de l'instruction qui provoque une exception qui doit être stocké dans `EPC`?
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- Une exception, c'est une erreur du programme, telle qu'une division par 0, une lecture non alignée ou une instruction illégale. Il est important que le gestionnaire d'exception sache quelle est l'instruction fautive. C'est pour cette raison que EPC contient l'adresse de l'instruction fautive. Le gestionnaire pourra lire l'instruction et éventuellement corriger le problème.
+- A titre indicatif, ce n'est pas question, mais pour les syscall, c'est aussi l'adresse de l'instruction syscall, or pour le retour du syscall, on souhaite aller à l'instruction suivante. Il faut donc incrémenter la valeur de `EPC` de 4 (les instructions font 4 octets) pour connaître l'adresse de retour.
+'''''''''''''''
+}}}
+1. Nous avons vu trois instructions ne sont pas utilisable lorsque le MIPS est en mode kernel, lesquelles? Que font-elles? Est-ce que `syscall` peut-être utilisée en mode user?
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- Les trois instructions sont 
+
+  || `mtc0 $GPR, $C0` || `M`ove `T`o `C`oprocessor `0`   || `$GPR` → COPRO_0(`$C0`)
+  || `mfc0 $GPR, $C0` || `M`ove `F`rom `C`oprocessor `0` || `$GPR` ←  COPRO_0(`$C0`)
+  || `eret`           || `E`xpection `RET`urn            || `PC`  ←  `EPC` ; `c0_sr.EXL`  ←  `0` 
+- Bien sûr que `syscall` peut être utilisé en mode user, puisque c'est comme ça qu'on entre dans le kernel.
+'''''''''''''''
+}}}
+1. Quelle est l'adresse d'entrée dans le noyau?
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- C'est `0x80000180`i. Il n'y a qu'un adresse pour toutes les causes syscall, exception et interruption.
+- En fait, on peut considérer que `0xBFC00000` permet aussi d'entrer dans le noyau après un reset. 
+'''''''''''''''
+}}}
+1. Que se passe-t-il quand le MIPS entre dans le noyau, après l'exécution de l'instruction `syscall`?
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- L'instruction `syscall` induit beaucoup d'opérations élémentaires:
+  - `EPC` ← `PC` (adresse de syscall)
+  - `c0_SR.EXL` ← `1`  (ainsi les bits `c0_SR.UM` et `c0_SR.IE` ne sont plus utilisés) 
+  - `c0_cause.XCODE` ← `8`
+  - `PC` ← `0x80000180`
+'''''''''''''''
+}}}
+1. Quelle instruction utilise-t-on pour sortir du noyau et entrer dans l'application ? Dîtes précisément ce que fait cette instruction dans le MIPS?
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- C'est l'instruction `eret` qui permet de sortir du noyau.
+  - `PC` ← `EPC`
+  - `c0_SR.EXL` ← `0` (ainsi les bits `c0_SR.UM` et `c0_SR.IE` sont à nouveau utilisés)
+'''''''''''''''
+}}}
+
+
+
+== A2. Langage C pour la programmation système
+
+
+La programmation en C, vous connaissez, mais quand on programme pour le noyau, c'est un peu différent. 
+Il y a des éléments de syntaxe ou des besoins spécifiques.
+
+
+**Questions**
+
+
+1. définition de section pour le placement des fonctions ou des variables?
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- 
+'''''''''''''''
+}}}
+1. effacement des variables globales?
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- 
+'''''''''''''''
+}}}
+1. accès aux registres de périphériques?
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- 
+'''''''''''''''
+}}}
+1. ldscript?
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- 
+'''''''''''''''
+}}}
+1. inclusion de code assembleur en C?
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- 
+'''''''''''''''
+}}}
+1. appel de code assembleur depuis le code C?
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- 
+'''''''''''''''
+}}}
+
+
+== A3. Passage entre les modes kernel et user
+
+
+Le noyau et l'application sont deux exécutables compilés indépendamment mais pas qui ne sont pas  indépendants. Vous savez déjà que l'application appelle les services du noyau avec l'instruction syscall, mais comment ça se passe vraiment depuis le code C et comment le noyau gère-t-il cet appel? En outre, il y a l'autre sens, comment le noyau lance-t-il l'application?
+
+
+**Questions**
+
+
+1. Comment imposer le placement d'adresse d'une fonction ou d'une variable en mémoire?
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- 
+'''''''''''''''
+}}}
+1. Convention utilisée pour que le noyau puisse lancer l'application?
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- 
+'''''''''''''''
+}}}
+1. Que faire avant et après l'exécution de la fonction `main()`?
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- 
+'''''''''''''''
+}}}
+1. Quels sont les évènements traités par le noyau?
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- 
+'''''''''''''''
+}}}
+1. le registre se réserve l'usage de deux registres, pourquoi et lesquels?
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- 
+'''''''''''''''
+}}}
+1. Comment le noyau traite les causes d'invocation?
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- 
+'''''''''''''''
+}}}
+1. comment fonctionne le gestionnaire de syscall?
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- 
+'''''''''''''''
+}}}
+1. comment fonctionne le gestionnaire d'appel système?
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- 
+'''''''''''''''
+}}}
+1. quels sont les fichiers communs?
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- 
+'''''''''''''''
+}}}
+
+
+== A4. Génération du code exécutable
+
+
+Pour simuler le logiciel, il faut produire deux exécutables. Nous utilisons, ici, un Makefile hiérarchique et des règles explicites. 
+Cela sort du cadre de l'architecture, mais vous avez besoin de ce savoir-faire pour comprendre le code, alors allons-y.
+
+
+**Questions**
+
+
+1. Rappelez là quoi sert un Makefile?
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- 
+'''''''''''''''
+}}}
+1. Comment appeler un makefile depuis une autre Makefile?
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- 
+'''''''''''''''
+}}}
+1. comment décrire une règle explicite?
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- 
+'''''''''''''''
+}}}
+1. comment utiliser les variables automatiques du C?
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- 
+'''''''''''''''
+}}}
+
+
+
+== A5. Libc 
+
+
+Cette partie ne concerne pas vraiment le noyau, mais il y a peut-être des choses que vous ignorez sur le C, ou certaines opérations, qu'il est nécessaire de connaître pour ce petit système. Cela n'a pas été présenté en cours, alors les questions sont précédées d'une présentation du problème et sa solution.
+
+
+**Questions**
+
+
+1. fonction C à nombre d'arguments variables `fprintf`?
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- 
+'''''''''''''''
+}}}
+1. génération de nombres pseudo-aléatoire `rand`?
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- 
+'''''''''''''''
+}}}
+1. traduction d'une chaîne de caractère en nombre `atoi`?
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- 
+'''''''''''''''
+}}}
+
+
+------------------------------------------------------------------------------------------------------------------------------------
+
+
+
+= B. Travaux pratiques
+
+
+
+Pour les travaux pratiques, vous devez d'abord répondre aux questions, elles ont pour but de vous faire lire le code et revoir les points du cours. Les réponses sont dans le cours ou dans les fichiers sources. Certaines ont déjà été traitées en TD, c'est normal. Ensuite, vous passez aux exercices pratiques.
+
+Le code se trouve dans `$AS5/tp2/`, ouvrez un terminal et allez-y. Dans ce répertoire, vous avez 4 sous-répertoires et un Makefile. Le fichier `$AS5/tp2/Makefile` permet de faire le ménage en appelant les Makefiles des sous-répertoires avec la cible `clean`.
+
+
+== B1. Ajout d'une bibliothèque de fonctions standard pour le kernel (klic)
+
+
+Le noyau gère les ressources matérielles et logicielles utilisées par les applications. Il a besoin de fonctions standards pour réaliser des opérations de base, telles qu'une fonction `print` ou une fonction `rand`. Ces fonctions ne sont pas très originales, mais elles recèlent des subtilités que vous ne connaissez peut-être pas encore. En outre, nous allons utiliser un Makefile définissant un graphe de dépendance explicite entre les fichiers cibles et les fichiers source avec des règles de construction.
+
+
+**Objectifs**
+
+
+- Ajouter une bibliothèque de fonctions standards
+- Utiliser un Makefile avec des règles explicites
+
+
+**Fichiers**
+
+
+{{{
+1_klibc/
+├── kinit.c         : fichier contenant la fonction de démarrage du noyau
+├── harch.h         : API du code dépendant de l'architecture
+├── harch.c         : code dépendant de l'architecture du SoC
+├── hcpu.h          : prototype de la fonction clock()
+├── hcpu.S          : code dépendant du cpu matériel en assembleur
+├── kernel.ld       : ldscript décrivant l'espace d'adressage pour l'éditeur de lien
+├── klibc.h         : API de la klibc
+├── klibc.c         : fonctions standards utilisées par les modules du noyau
+└── Makefile        : description des actions possibles sur le code : compilation, exécution, nettoyage, etc.
+}}}
+
+
+**Questions**
+
+
+1. En ouvrant tous les fichiers dessiner le graphe de dépendance de `kernel.x` vis-à-vis de ses sources?
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- kernel.x : kinit.o harch.o hcpu.o
+- kinit.o : etc.
+
+'''''''''''''''
+}}}
+1. ? 
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- 
+'''''''''''''''
+}}}
+
+
+**Exercices
+
+
+* Ajout de la fonction cpuid() qui lit le registre $15 du coprocesseur système.
+
+
+== B2. Programme utilisateur mais exécuté en mode kernel
+
+
+Nous allons désormais avoir deux exécutables: le noyau et l'application. Dans cette étape, nous allons voir comment le noyau fait pour appeler l'application, alors que celle-ci n'est pas compilée en même temps que le noyau.
+
+
+**Objectifs**
+
+
+**Fichiers**
+
+{{{
+2_appk/
+├── Makefile        : Makefile racine qui invoque les Makefiles des sous-répertoires et qui exécute
+├── kernel ────────── Répertoire des fichiers composant le kernel 
+│   ├── kinit.c     : fichier contenant la fonction de démarrage du noyau
+│   ├── harch.h     : API du code dépendant de l'architecture
+│   ├── harch.c     : code dépendant de l'architecture du SoC
+│   ├── hcpu.h      : prototype de la fonction clock()
+│   ├── hcpu.S      : code dépendant du cpu matériel en assembleur
+│   ├── klibc.h     : API de la klibc
+│   ├── klibc.c     : fonctions standards utilisées par les modules du noyau
+│   ├── kernel.ld   : ldscript décrivant l'espace d'adressage pour l'édition de liens du kernel
+│   └── Makefile    : description des actions possibles sur le code kernel : compilation et nettoyage
+└── user ──────────── Répertoire des fichiers composant l'application user 
+    ├── crt0.c      : fonctions d'interface entre kernel et user, pour le momment : crt0()
+    ├── main.c      : fonction principale de l'application
+    ├── user.ld     : ldscript décrivant l'espace d'adressage pour l'édition de liens du user
+    └── Makefile    : description des actions possibles sur le code user : compilation et nettoyage
+}}}
+
+**Questions**
+
+1. Question ? 
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- réponse
+'''''''''''''''
+}}}
+
+
+
+== B3. Programme utilisateur utilisé en mode user mais sans libc
+
+
+
+Le programme utilisateur doit absolument s'exécuter en mode user et il doit passer par des appels système pour accéder aux services du noyau. Les services, ici, sont limités (l'accès au TTY, exit et clock), il n'empêche que pour gérer ces appels, il faut l'analyseur des causes d'appels à l'entrée du noyau et un gestionnaire de `syscall`. Il faut aussi le gestionnaire d'exceptions, parce que s'il y a une erreur de programmation, le noyau doit afficher quelque chose pour aider le programmeur. 
+
+
+**Objectifs**
+
+ 
+**Fichiers**
+
+{{{
+3_syscalls/
+├── Makefile        : Makefile racine qui invoque les Makefiles des sous-répertoires et qui exécute
+├── common ────────── répetoire des fichiers commun kernel / user
+│   └── syscalls.h  : API la fonction syscall et des codes de syscalls
+├── kernel ────────── Répertoire des fichiers composant le kernel 
+│   ├── kinit.c     : fichier contenant la fonction de démarrage du noyau
+│   ├── harch.h     : API du code dépendant de l'architecture
+│   ├── harch.c     : code dépendant de l'architecture du SoC
+│   ├── hcpu.h      : prototype de la fonction clock()
+│   ├── hcpu.S      : code dépendant du cpu matériel en assembleur
+│   ├── klibc.h     : API de la klibc
+│   ├── klibc.c     : fonctions standards utilisées par les modules du noyau
+│   ├── kpanic.h    : déclaration du tableau de dump des registres en cas d'exception
+│   ├── kpanic.c    : fonction d'affichage des registres avant l'arrêt du programme
+│   ├── ksyscalls.c : Vecteurs des syscalls
+│   ├── kernel.ld   : ldscript décrivant l'espace d'adressage pour l'édition de liens du kernel
+│   └── Makefile    : description des actions possibles sur le code kernel : compilation et nettoyage
+└── user ──────────── Répertoire des fichiers composant l'application user 
+    ├── crt0.c      : fonctions d'interface entre kernel et user, pour le momment : crt0()
+    ├── main.c      : fonction principale de l'application
+    ├── user.ld     : ldscript décrivant l'espace d'adressage pour l'édition de liens du user
+    └── Makefile    : description des actions possibles sur le code user : compilation et nettoyage
+}}}
+
+**Questions**
+
+1. Question ? 
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- réponse
+'''''''''''''''
+}}}
+
+
+
+
+== B4.  Accès aux registres de contrôle des terminaux `TTY`
+
+
+
+**Objectifs**
+
+ 
+**Fichiers**
+
+{{{
+4_libc/
+├── Makefile        : Makefile racine qui invoque les Makefiles des sous-répertoires et qui exécute
+├── common ────────── répetoire des fichiers commun kernel / user
+│   └── syscalls.h  : API la fonction syscall et des codes de syscalls
+├── kernel ────────── Répertoire des fichiers composant le kernel 
+│   ├── kinit.c     : fichier contenant la fonction de démarrage du noyau
+│   ├── harch.h     : API du code dépendant de l'architecture
+│   ├── harch.c     : code dépendant de l'architecture du SoC
+│   ├── hcpu.h      : prototype de la fonction clock()
+│   ├── hcpu.S      : code dépendant du cpu matériel en assembleur
+│   ├── klibc.h     : API de la klibc
+│   ├── klibc.c     : fonctions standards utilisées par les modules du noyau
+│   ├── kpanic.h    : déclaration du tableau de dump des registres en cas d'exception
+│   ├── kpanic.c    : fonction d'affichage des registres avant l'arrêt du programme
+│   ├── ksyscalls.c : Vecteurs des syscalls
+│   ├── kernel.ld   : ldscript décrivant l'espace d'adressage pour l'édition de liens du kernel
+│   └── Makefile    : description des actions possibles sur le code kernel : compilation et nettoyage
+├── uapp ──────────── Répertoire des fichiers de l'application user seule
+│   ├── main.c      : fonction principale de l'application
+│   └── Makefile    : description des actions possibles sur le code user : compilation et nettoyage
+└── ulib ──────────── Répertoire des fichiers des bibliothèques système liés avec l'application user
+    ├── crt0.c      : fonctions d'interface entre kernel et user, pour le momment : crt0()
+    ├── libc.h      : API pseudo-POSIX de la bibliothèque C
+    ├── libc.c      : code source de la libc
+    ├── main.c      : fonction principale de l'application
+    ├── user.ld     : ldscript décrivant l'espace d'adressage pour l'édition de liens du user
+    └── Makefile    : description des actions possibles sur le code user : compilation et nettoyage
+
+}}}
+
+**Questions**
+
+1. Question ? 
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- réponse
+'''''''''''''''
+}}}
+