< Un système multi-tâches simple | TutoOS | Booter avec Grub >

Un noyau multi-tâches avec des appels systèmes préemptibles

• Un scheduler qui tient compte du contexte d'exécution
• Utiliser les TrapGate pour rendre les appels systèmes interruptibles

Sources

Le package contenant les sources est téléchargeable ici : kernel_MultiTask_Preemptible.tgz
Pour naviguer dans l'arborescence : MultiTask_Preemptible

Un scheduler qui tient compte du contexte d'exécution

Une pile noyau par tâche : pourquoi ?

Quand une tâche fait un appel système, la pile noyau est automatiquement utilisée par le processeur. Les routines de traitement de cet appel utilisent alors cette pile pour stocker des données, passer des paramètres à des fonctions, etc. Une fois que l'appel système est terminé, les données temporaires sont dépilées et la pile noyau retourne à son état initial, telle qu'elle était avant l'appel.

Si l'on autorise les interruptions et la commutation de tâches pendant un appel système, voilà ce qui risque de se passer :

1. Par exemple, la tâche A fait un appel système et utilise la pile noyau pour traiter cet appel.
2. L'ordonanceur est activé alors que l'appel n'est pas terminé et il donne la main à la tâche B.
3. La tâche B fait elle aussi un appel système, et elle utilise donc elle aussi la pile du noyau qui contenait déja les données en cours pour le traitement de l'appel de la tâche A. A ce moment, la pile noyau contient des données de A et des données de B.
4. L'ordonnanceur active de nouveau la tâche A et celle-ci reprend sans se douter que la pile a été modifiée. Comme elle va utiliser la pile en supposant qu'elle est dans l'état où elle l'avait laissé, elle va corrompre les données de la tâche B.
5. La tâche B reprend mais la pile est corrompue... et c'est le drame !

Pour éviter ce scénario catastrophe, il existe une solution très simple : il suffit que chaque tâche ait sa propre pile noyau !

Une pile noyau par tâche : comment

La fonction load_task() est modifiée afin d'associer à chaque tâche sa propre pile noyau : process.c.

Le code ci-dessous alloue à une tâche sa propre pile noyau. Par simplicité, une pile occupe une page :

Suite à une interruption, le processeur empile automatiquement des données sur la pile noyau de la tâche interrompue, sans compter celles ajoutées par les différentes routines du noyau. Il est crucial qu'à l'issue d'une interruption, la pile noyau utilisée soit remise dans le même état qu'avant l'interruption.

L'ordonnanceur

La complexité de l'ordonnanceur provient essentiellement des difficultés induites par la gestion des différentes piles noyau et utilisateur.

Le code de l'ordonnanceur est réparti dans deux fichiers :

• schedule.c contient la partie préparatoire au changement de contexte

• sched.asm contient le code qui effectue effectivement le changement de contexte

Le design de l'ordonnanceur est plus compliqué car :

• Il doit prendre en compte le contexte de la tâche lors de son interruption.
• Chaque tâche a sa propre pile noyau.
• L'ordonnanceur change de pile noyau pendant la commutation.
• La pile noyau ne contient pas le même nombre de registres empilés selon que la tâche interrompue était en mode utilisateur ou en mode noyau. L'interruption d'une tâche en mode utilisateur provoque automatiquement l'empilement des registres ss, esp, eflags, cs et eip. Quand l'interruption survient alors que la tâche est en mode noyau, les seuls registres empilés sont : eflags, cs et eip.

Schémas de la pile noyau après l'interruption d'une tâche en mode utilisateur :

Schémas de la pile noyau après l'interruption d'une tâche en mode noyau :

Toutes les contraintes supportées par l'ordonnanceur peuvent se résumer à :

• sauvegarder les registres de la tâche interrompue
• remettre la pile noyaux dans l'état précédent l'interruption avant de quitter celle-ci

Le schéma suivant représente la pile noyau lors de l'appel à la fonction schedule() dans le cas où le processeur était en mode utilisateur lors de l'interruption : pile

Attention ! Cette représentation de la pile illustre le cas où le processeur était en mode utilisateur lors de l'interruption.

Dans le cas où le processeur était en mode noyau au moment de l'interruption, le schéma est très sensiblement différent car les registres ss et esp n'ont pas été empilés.

Notre but est de sauvegarder l'état de l'ensemble des registres de la tâche interrompue, ce qui ne pose aucun problème pour l'ensemble d'entre eux (eax, ebx, etc.). La seule difficulté est de retrouver les valeurs de ss et de esp juste avant l'interruption d'horloge car si l'interruption est survenue pendant un appel système, on ne peut procéder de la même façon pour retrouver ces valeurs car elles n'ont pas été empilées :

• Le premier cas est celui de l'interruption d'une tâche en mode utilisateur. L'appel système a sauvegardé tous les registres, dont ss et esp, sur la pile noyau de la tâche. C'est un cas assez simple déjà vu au chapitre précédent.
• Le deuxième cas concerne l'interruption d'une tâche en mode noyau. Le processeur utilisait la même pile avant l'interruption et esp pointait juste au sommet des registres empilés par l'interruption. Pour retrouver cette valeur, plusieurs calculs sont possibles :
  • stack_ptr[9] contient la valeur du pointeur de pile juste après l'interruption (et avant l'appel à push et à pushad). Avant l'interruption, esp pointait sur la même pile mais juste avant les trois registres eflags, cs et eip empilés par l'interruption. Nous avons donc : 3 registres * 4 octets par registre = 12. stack_ptr[9] + 12 pointe donc au sommet de la pile.
  • Le sommet de la pile est situé 17 registres au-dessus du pointeur stack_ptr, on pourrait donc utiliser l'un des deux calculs suivants : stack_ptr + 17 * 4 ou &stack_ptr[17].

Après avoir sélectionné une nouvelle tâche, pointée par *p, l'ordonnanceur teste si cette nouvelle tâche à activer avait été interrompue en mode utilisateur ou en mode noyau. La fonction switch_to_task() est appelé avec le pid de la tâche à activer et le mode dans lequel il faut l'activer :

La fonction switch_to_task()

La fonction switch_to_task() prépare la commutation :

• elle change de pile noyau et passe sur la pile de la nouvelle tâche
• elle empile les registres nécessaire à l'instruction iret
• elle passe la main à la fonction do_switch() qui charge les registres et effectue la commutation

Les variables current->regs.ss, current->regs.cs et current->regs.eflags ne peuvent être directement utilisées dans la fonction asm(). Ces trois affectations initialisent des variables qui pourront elles être passées en paramètre à la fonction assembleur :

Ce code récupère les paramètres de la pile noyau pour la nouvelle tâche. Si celle-ci est en mode utilisateur, on va utiliser une pile noyau "propre". Si en revanche elle est en mode noyau, il suffit de reprendre les valeurs ss et esp sauvegardées lors du changement de contexte :

Cette fonction effectue un gros travail :

1. les deux premières instruction basculent sur la nouvelle pile noyau
2. si la tâche est en mode utilisateur, elle empile les valeurs sauvegardées des registres ss et esp
3. elle empile les valeurs sauvegardées des registres eflags, cs et eip
4. elle passe la main à la fonction do_switch() qui charge les registres avec les valeurs sauvegardées et effectue la commutation avec iret

Utiliser les TrapGate pour rendre les appels systèmes interruptibles

Les appels systèmes sont rendus interruptibles :

Pour tester le fait qu'ils sont bien interruptibles, une temporisation est ajoutée pour les rendre plus lent : syscalls.c.

L'utilisation de la fonction cli peut cependant être requis car il n'est pas souhaitable qu'un appel système soit interrompu à certains moments critiques de son exécution. Notament ici, pour avoir un affichage cohérent, j'ai préféré désactiver les interruptions le temps de l'affichage de la chaîne.

< Un système multi-tâches simple | TutoOS | Booter avec Grub >