Changes between Version 40 and Version 41 of Archi-1-TP10

Timestamp:

Jan 2, 2021, 10:05:54 PM (4 years ago)

Author:

franck

Comment:

--

Archi-1-TP10

@@ -557 +557 @@
 
 
+
+**Objectifs de l'étape**
+
 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, vous pouvez les regarder par curiosité. En outre, nous allons utiliser un Makefile définissant un graphe de dépendance explicite entre les fichiers cibles et les fichiers sources avec des règles de construction.
-
-
-**Objectifs de l'étape**
-
-
-- Usage d'une bibliothèque de fonctions standards pour le noyau.
-- Usage d'un Makefile avec des règles explicites.
 
 
@@ -617 +613 @@
 
 
-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. Nous allons passer du noyau à l'application à la fin de la fonction `kinit()`.\\
+**Objectifs de l'étape**
+
+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. Nous allons passer du noyau à l'application à la fin de la fonction `kinit()`.
+
 En revanche, dans cette étape, nous n'allons pas mettre en place la gestion des syscalls. C'est-a-dire qu'il ne sera pas possible de revenir dans le noyau depuis l'application. C'est bien entendu une étape intermédiaire, parce qu'il faut normalement absolument pouvoir invoquer le noyau depuis l'application pour accéder aux périphériques. 
-Toutefois, pour pouvoir quand même accéder aux registres de périphériques, nous allons exceptionnellement exécuter l'application en mode kernel. Ainsi, l'application pourra accéder aux adresses de l'espace d'adressages réservées aux mode `kernel`.
-
-
-**Objectifs de l'étape**
-
-- Ecrire une application en dehors du kernel et voir comment le kernel entre dans l'application.
+Toutefois, pour pouvoir quand même accéder aux registres de périphériques, nous allons exceptionnellement exécuter l'application en mode kernel. Ainsi, l'application pourra accéder aux adresses de l'espace d'adressage réservées aux mode `kernel`.
+
+Nous avons deux exécutables à compiler et donc deux `Makefile`s de compilation. Nous avons aussi un `Makefile` qui invoque récursivement les `Makefile`s de compilation.
+
 
 **Fichiers**
@@ -650 +647 @@
 **Questions**
 
+1. Combien de fichiers de type ldscript avons-nous ?
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- Il en faut deux, un pour le kernel `kernel/kernel.ld` et un pour l'application `user/user.d'
+'''''''''''''''
+}}}
 1. Dans quel fichier se trouve la première fonction de l'application et comment s'appelle-t-elle?
 {{{#!protected ------------------------------------------------------------------------------------
@@ -682 +685 @@
 - Vous n'allez pas faire grand-chose pour cette étape parce qu'elle n'est pas très utile du fait de l'impossibilité de revenir dans le noyau après l'entrée dans l'application. Affichez juste un second message depuis la fonction `main()`
 
+
+
 == 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**
-
- 
+**Objectifs de l'étape**
+
+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.
+
+Le passage de l'application au noyau par le biais de l'instruction `syscall` impose que les numéros de services soient identiques pour le noyau et pour l'application. Ces numéros de service (comme `SYSCALL_TTY_WRITE`, `SYSCALL_EXIT` sont défins dans un `.h` commun aux noyau et à l'application. Ce fichier est mis dans un répertoire à part nommé `common`. Il n'y a qu'un seul fichier ici, mais dans un système plus élaborés il y en a d'autres.
+
+
 **Fichiers**
 
@@ -721 +727 @@
 **Questions**
 
-1. Question ? 
-{{{#!protected ------------------------------------------------------------------------------------
-'''''''''''''''
-- réponse
-'''''''''''''''
-}}}
+1. Dans quel fichier se trouve la définition des numéros de services tels que `SYSCALL_EXIT` ? 
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- 
+'''''''''''''''
+}}}
+1. Dans quel fichier se trouve le vecteur de syscall, c'est-à-dire le tableau `syscall_vector[]` contenant les pointeurs sur les fonctions qui réalisent les services correspondants aux syscall ? 
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- 
+'''''''''''''''
+}}}
+1. Dans quel fichier se trouve le gestionnaire de syscalls ? 
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+- 
+'''''''''''''''
+}}}
+
+
+**Exercice** 
+
+- Vous allez ajouter un appel système qui rend le numéro du processeur.