Changes between Version 51 and Version 52 of AS6-TME-B6

Timestamp:

Mar 30, 2022, 8:42:49 AM (3 years ago)

Author:

franck

Comment:

--

AS6-TME-B6

@@ -386 +386 @@
 Vous savez peut-être que dans un processeur disposant d'un mécanisme permettant à chaque application d'avoir son propre espace d'adressage (espace d'adressage virtuel), les accès à la mémoire passe par un composant de traduction d'adresses nommé **MMU** pour traduire les adresses virtuelles de l'application en adresses physiques de l'espace d'adressage physique où se trouvent les segments de mémoire physique (gérés par les bancs de mémoire). 
 
-L'un des rôles de ce composant **MMU** (Memory Management Unit) est de tester la légalité des accès à la mémoire. Si le noyau attribut un segment d'adresses à une application. Si l'application tente d'accéder en dehors de ce segment, la MMU le détecte et prévient le noyau par une exception. C'est l'erreur ''Segmentation Fault'' que vous avez certainement déjà eu.
+L'un des rôles de ce composant **MMU** (Memory Management Unit) est de tester la légalité des accès à la mémoire. Si le noyau attribut un segment d'adresses à une application. Si l'application tente d'accéder en dehors de ce segment, la MMU le détecte et prévient le noyau par une exception. C'est l'erreur fatale ''Segmentation Fault'' que vous avez certainement déjà eu.
 
 Le SoC **almo1** n'a pas de MMU, donc pas de gestion de mémoire virtuelle, or nous voulons tester que les segments d'adresses définis pour les deux piles de threads ne débordent pas. Pour ce faire, les deux piles de threads (user et kernel) ont des nombres magiques (`MAGIC_STACK`) dans leur premier et dernier mot. Ces mots ne devraient jamais être écrasés, si cela se produit, c'est que les piles ont été corrompues ou qu'elles ont débordé. 
@@ -392 +392 @@
 L'idée est de tester à intervalle régulier que les nombres magiques sont toujours présents, par exemple lors des changements de threads. C'est un bon moment parce qu'on peut tester que les piles du thread sortant n'ont pas débordé pendant son exécution et que les piles du thread entrant sont correctes avant de lui donner un cœur. 
 
+**kernel/kthread.c**
+
+ La fonction `sched_switch()` est la fonction de l'ordonnanceur de thread qui réalise le changement de thread. Dans cette fonction, `ThreadCurrent` est le pointeur sur la structure `kthread_t` du thread courant, c'est-à-dire, d'abord le thread sortant puis le thread entrant (2e instruction du `if`). 
+
+{{{#!c
+static void sched_switch (void)
+{
+    int th_curr = ThreadCurrentIdx;                         // get the current thread index
+    int th_next = sched_elect ();                           // get a next ready thread
+    if (th_next != th_curr) {                               // if it is not the same
+        if (thread_save (ThreadCurrent->context)){          // Save current context, and return 1
+            ThreadCurrentIdx = th_next;                     // update ThreadCurrentIdx
+            ThreadCurrent = ThreadTab[th_next];             // update ThreadCurrent
+            thread_load (ThreadCurrent->context);           // load context & exit from thread_save
+        }                                                   // but with 0 as return value
+    }
+    ThreadCurrent->state= TH_STATE_RUNNING;                 // the chosen one is RUNNNIG
+}
+}}}
+
+
+Ajouter les lignes nécessaires pour tester la présence des nombres magiques, sinon c'est la panique :-)
+Vous pouvez utiliser la macro `PANIC_IF(cond,fmt,arg...)` qui, si `cond` est vrai, affiche un message définit par `fmt` et `arg...` et stoppe l'application par l'appel de `kpanic()`. Par exemple:
+
+{{{#!c
+PANIF_IF( A != 3 , "Argh, A is not equal to 2, it is %d", A);
+}}}
 
 == B.4. Faire en sorte que les listes d'objets libres du noyau ne retombent à 0