Changes between Version 32 and Version 33 of Archi-1-TP10

Timestamp:

Jan 2, 2021, 12:03:10 PM (4 years ago)

Author:

franck

Comment:

--

Archi-1-TP10

@@ -361 +361 @@
 '''''''''''''''
 }}}
-1. Le gestionnaire de syscall est la partie du code qui gère le comportement du noyau lors de l'exécution de l'instruction `syscall`. C'est un code en assembleur présent dans le fichier `kernel/hcpu.S` que nous allons observer. Pour vous aider dans la compréhension de ce code, vous devez imaginer que l'instruction `syscall` est un peu comme un appel de fonction. Ce code utilise un tableau de pointeurs de fonctions nommé `syscall_vector` définit dans le fichier `kernel/ksyscalls.c`. Les lignes `36` à `43` sont chargées d'allouer dans la pile. Dessinez l'état de la pile après l'exécution de ces instructions. Que fait l'instruction lige `44` et quelle conséquence cela a? Que font les lignes `46` à `52`? Et enfin que font les lignes `54` à `60`\\ \\**`kernel/ksyscalls.c`**
+1. Le gestionnaire de syscall est la partie du code qui gère le comportement du noyau lors de l'exécution de l'instruction `syscall`. C'est un code en assembleur présent dans le fichier `kernel/hcpu.S` que nous allons observer. Pour vous aider dans la compréhension de ce code, vous devez imaginer que l'instruction `syscall` est un peu comme un appel de fonction. Ce code utilise un tableau de pointeurs de fonctions nommé `syscall_vector` définit dans le fichier `kernel/ksyscalls.c`. Les lignes `36` à `43` sont chargées d'allouer dans la pile. Dessinez l'état de la pile après l'exécution de ces instructions. Que fait l'instruction lige `44` et quelle conséquence cela a? Que font les lignes `46` à `52`? Et enfin que font les lignes `54` à `60`\\ \\**`common/syscalls.h`**
+{{{#!c
+  1 #define SYSCALL_EXIT        0
+  2 #define SYSCALL_TTY_WRITE   1
+  3 #define SYSCALL_TTY_READ    2
+  4 #define SYSCALL_CLOCK       3
+  5 #define SYSCALL_NR          32
+}}}
+  **`kernel/ksyscalls.c`**
 {{{#!c
 void *syscall_vector[] = {
@@ -423 +431 @@
       +----------+
 }}}
-- L'instruction ligne 44 met `0` dans le registre `c0_sr`. Ce qui a pour conséquence de mettre à `0` les bits `UM`, `EXL` et `IE`. On est donc en mode kernel avec interruptions masquées. Notez qu'interdire les interruptions pendant l'exécution des syscall est contraignant. Pour le moment, ce n'est pas important puisque nous ne traitons pas encore les interruptions, mais lorsque nous les traiterons, elles seront masquées. En conséquence, il sera interdit aux fonctions qui traitent les appels système d'exécuter des attentes longues (comme une boucle qui attend le changement d'état d'un registre de périphérique) car sinon, le noyau sera bloqué (plus rien ne bouge).
+- L'instruction ligne 44 met `0` dans le registre `c0_sr`. Ce qui a pour conséquence de mettre à `0` les bits `UM`, `EXL` et `IE`. On est donc en mode kernel avec interruptions masquées.\\ \\''Notez qu'interdire les interruptions pendant l'exécution des syscall est contraignant. Pour le moment, ce n'est pas important puisque nous ne traitons pas encore les interruptions, mais lorsque nous les traiterons, elles seront masquées. En conséquence, il sera interdit aux fonctions qui traitent les appels système d'exécuter des attentes longues (comme une boucle qui attend le changement d'état d'un registre de périphérique) car sinon, le noyau sera bloqué (plus rien ne bouge).''
+- Commentaire du code
+  - Ligne 46 : $26 **←** l'adresse du tableau syscall_vector\\⟶ On s'apprête à y faire un accès indexé par le registre $2
+  - Ligne 47 : $2  **←** $2 @ 0x1F \\⟶ 
+  - Ligne 48 :  **←**  \\⟶ 
+  - Ligne 49 :  **←**  \\⟶ 
+  - Ligne 50 :  **←**  \\⟶ 
+  - Ligne 51 :  **←**  \\⟶ 
+  - Ligne 52 :  **←**  \\⟶ 
 '''''''''''''''
 }}}