DOCS [Start][Config][User][Kernel] — COURS [9] [9bis] [10] [10bis] [11] — TD [​9][​10][​11] — TP [​9][10][​11] — ZIP [gcc...][9][10][11]

Application simple en mode utilisateur

Le TP est découpé en 4 étapes. Pour chaque étape, nous donnons (1) une brève description avec une liste des objectifs principaux de l'étape, (2) une liste des fichiers avec un bref commentaire sur chaque fichier, (3) une liste de questions simples dont les réponses sont dans le code, le cours ou le TD et enfin (4) un petit exercice de codage.

IMPORTANT
Avant de faire cette séance, vous devez avoir lu les documents suivants :

• Séance de TP sur le démarrage du prototype : obligatoire
• Cours sur l'exécution d'une application en mode user : obligatoire
• Document sur l'assembleur du MIPS et la convention d'appel des fonctions : recommandé, mais déjà lu
• Documentation sur le mode kernel du MIPS32 : obligatoire

Récupération du code du TP

• Téléchargez l'archive code du tp2 et placez là dans le répertoire $HOME/kO6
• Ouvrez un terminal
• Allez dans le répertoire kO6 : cd ~/kO6
• Décompressez l'archive du tp2 : tar xvzf tp2.tgz
• Exécutez la commande : cd ; tree -L 1 kO6/tp2.
  Vous devriez obtenir ceci :

  kO6/tp2
  ├── 1_klibc
  ├── 2_appk
  ├── 3_syscalls
  ├── 4_libc
  └── Makefile
  

Objectif de la séance

Cette séance illustre le 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 de faire l'accès. C'est ce que nous allons voir.

Le code est désormais découpé en 4 étapes :

• 1_klibc
  ⟶ Le code de boot et kinit() avec une librairie de fonctions standard pour le noyau;
• 2_appk
  ⟶ La fonction d'initialisation kinit() appelle une application mais le noyau n'a pas encore le gestionnaire des appels systèmes;
• 3_syscalls
  ⟶ Ajout du gestionnaire des appels système et une application sans la librairie de fonctions standards utilisateur (libc);
• 4_libc
  ⟶ Ajout de la libc (rudimentaire) et d'une application.

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 et vous guidez, un peu, pour l'exercice. 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 kO6/tp2/, ouvrez un terminal et allez-y. Dans ce répertoire, vous avez 4 sous-répertoires et un Makefile. Le fichier kO6/tp2/Makefile permet de faire le ménage en appelant les Makefiles des sous-répertoires avec la cible clean.

1. Ajout d'une bibliothèque de fonctions standards pour le kernel (klibc)

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.

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()
├── hcpua.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. Ouvrez le fichier Makefile (vous pouvez regarder les dépendances en ouvrant quelques fichiers sources), puis dessiner le graphe de dépendance de kernel.x vis-à-vis de ses sources?
   La réponse peut-être visible avec la commande dot -Tpng Makefile.dot -oMakefile.png à partir du fichier Makefile.dot (lien cliquable) en utilisant ​graphviz ... essayez c'est magique :-)
2. Dans quel fichier se trouvent les codes dépendant du MIPS ?

Exercices

• Le numéro du processeur est dans les 12 bits de poids faible du registre $15 (c0_cpuid) du coprocesseur système (à côté des registres c0_epc, c0_sr, etc.). Ajoutez la fonction int cpuid(void) qui lit le registre c0_cpuid et qui rend un entier contenant juste les 12 bits de poids faible.
  Vous pouvez vous inspirez fortement de la fonction int clock(void). Comme il n'y a qu'un seul processeur dans cette architecture, cpuid rend toujours 0.
  Ecrivez un programme de test (vous devrez modifier les fichiers hcpu.h, hcpua.S et kinit.c)

2. Programme utilisateur mais exécuté en mode kernel

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 même 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().

Nous allons donc entrer dans l'application, en revanche, dans cette étape, nous n'allons pas mettre en place la gestion des syscalls. C'est-à-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 absolument pouvoir invoquer le noyau depuis l'application pour accéder aux périphériques. 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 au mode kernel.

Nous avons deux exécutables à compiler et donc deux Makefiles de compilation. Nous avons aussi un Makefile qui invoque récursivement les Makefiles de compilation.

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()
│   ├── hcpua.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 moment : _start()
    ├── 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. Combien de fichiers de type ldscript avons-nous ?
2. Dans quel fichier se trouve la première fonction de l'application et comment s'appelle-t-elle?
3. Quelle est la fonction du noyau qui appelle cette fonction et dans quel fichier?
4. Comment le noyau fait-il pour démarrer l'application en mode kernel? (la réponse est dans la fonction de la question précédente).

Exercice

• 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()

3. Programme utilisateur utilisé en mode user mais sans libc

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_PUTS, SYSCALL_EXIT sont définis dans le fichier syscall.h communs au 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é, il y en a d'autres.

Fichiers

3_syscalls/
├── Makefile        : Makefile racine qui invoque les Makefiles des sous-répertoires et qui exécute
├── common ────────── répertoire 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()
│   ├── hcpua.S     : code dépendant du cpu matériel en assembleur
│   ├── hcpuc.c     : code dépendant du cpu matériel en c
│   ├── 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 moment : _start()
    ├── 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. Dans quel fichier se trouve la définition des numéros de services tels que SYSCALL_EXIT ? (Ces numéros sont communs au noyau et à l'application)
2. 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 ?
3. Dans quel fichier se trouve le gestionnaire de syscalls ? (c'est de l'assembleur)

Exercice

• Vous allez ajouter un appel système nommé SYSCALL_CPUID qui rend le numéro du processeur. Nous allons lui attribuer le numéro 6 (notez que ces numéros de services n'ont rien à voir avec les numéros utilisés pour le simulateur MARS). Pour ajouter un appel système, vous devez modifier les fichiers : common/syscalls.h, kernel/ksyscall.c, kernel/hcpua.S et kernel/hcpu.h.cpuid(void)`.

4. Ajout de la librairie C pour l'utilisateur

Objectifs de l'étape

L'application utilisateur n'est pas censée utiliser directement les appels système. Elle utilise une librairie de fonctions standards (la libc POSIX, mais pas seulement) et ce sont ces fonctions qui réalisent les appels système. Toutes les fonctions de la libc n'utilisent pas les appels système. Par exemple, les fonctions int rand(void) ou int strlen(char *) (rendent, respectivement, un nombre pseudo aléatoire et la longueur d'une chaîne de caractères) n'ont pas besoin du noyau. Les librairies font partie du système d'exploitation mais elles ne sont pas dans le noyau.

Le terme « librairie » vient de l'anglais « library » qui signifie bibliothèque. On utilise souvent le mot librairie même si le sens en français n'est pas le même que celui en anglais. Disons que, dans notre contexte, les deux mots sont synonymes.

Normalement, les librairies système sont des « vraies » librairies au sens gcc du terme. C'est-à-dire des archives de fichiers objet (.o). Ici, nous allons simplifier et ne pas créer une vraie librairie, mais seulement un fichier objet libc.o contenant toutes les fonctions. Ce fichier objets doit être lié avec le code de l'application.

L'exécutable de l'application utilisateur est donc composé de deux parties : d'un côté, le code de l'application et, de l'autre, le code de la librairie libc (+ crt0). Nous allons répartir le code dans deux répertoires uapp pour les fichiers de l'application et ulib pour les fichiers qui ne sont pas l'application, c'est-à-dire la libc, le fichier crt0.c mais aussi le fichier ldscript user.ld.

Fichiers

4_libc/
├── Makefile        : Makefile racine qui invoque les Makefiles des sous-répertoires et qui exécute
├── common ────────── répertoire 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()
│   ├── hcpua.S     : code dépendant du cpu matériel en assembleur
│   ├── hcpuc.c     : code dépendant du cpu matériel en c
│   ├── klibc.h     : API de la klibc
│   ├── klibc.c     : fonctions standards utilisées par les modules du noyau
│   ├── 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 moment : _start()
    ├── libc.h      : API pseudo-POSIX de la bibliothèque C
    ├── libc.c      : code source de la libc
    ├── 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. Pour ce petit système, dans quel fichier sont placés tous les prototypes des fonctions de la libc? Est-ce ainsi pour POSIX sur LINUX?

Exercice

• Vous allez juste ajouter la fonction int cpuid() dans la librairie libc.
• Au premier TP, vous deviez créer un petit jeu 'guess', vous pouvez en faire une application utilisateur, en utilisant cette fois les fonctions de la libc.