| Version 47 (modified by , 4 years ago) (diff) |
|---|
Cette page décrit la séance complète : partie TD et partie TP. Elle commence par la partie TD avec des questions ou des exercices à faire sur papier, réparties dans 4 sections. Certaines questions de sections différentes sont semblables, c'est normal, cela vous permet de réviser. Puis, dans la partie TP, il y a des questions sur le code avec quelques exercices de codage simples à écrire et à tester sur le prototype. La partie TP est découpée 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 TME 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é
- 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/AS5 - Assurez-vous que vous avez déjà sourcé le fichier
Source-me.sh(sinon lisez Configuration de l'environnement des TP → Étape 3) - Ouvrez un
terminal, allez dans le répertoireAS5(cd ~/AS5) et décompressez l'archive du tp2 avectar xvzf tp2.tgz
Cette étape est peut-être inutile si vous avez déjà fait la décompression de l'archive au moment de son téléchargement. - Dans le
terminal, exécutez la commandecd ; tree -L 2 AS5. Vous devriez obtenir ceci (tp1 et tp2):AS5 ├── bin │ ├── almo1.x │ ├── gcc │ ├── Source-me.sh │ ├── test │ └── tracelog ├── tp1 │ ├── 1_hello_boot │ ├── 2_init_asm │ ├── 3_init_c │ ├── 4_nttys │ ├── 5_driver │ └── Makefile └── 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 couches logicielles :
1_klibc
⟶ le code de boot (utilisé seulement au démarrage) mais avec une librairie de fonctions standard pour le noyau;2_appk
⟶ le noyau du système d'exploitation, ici pour l'essentiel, la fonction d'initialisationkinit()
et une application mais sans le gestionnaire des appels systèmes;3_syscalls
⟶ le noyau avec le gestionnaire des appels système et une application sans la librairie de fonctions standards (libc);4_libc
⟶ le noyau avec gestionnaire de syscall, une libc, et une application
A. Travaux dirigés
A1. Les modes d'exécution du MIPS
Dans cette section, nous allons nous intéresser à ce que propose le processeur MIPS concernant les modes d'exécution. Ce sont des questions portant sur l'usage des modes en général et le comportement du MIPS vis-à-vis de ces modes en particulier. Dans la section A3, nous verrons le code de gestion des changements de mode dans le noyau.
Questions
- Le MIPS propose deux modes d'exécution, rappelez quels sont ces deux modes et à quoi ils servent? (Nous l'avons dit dans le descriptif de la séance).
- Commencez par rappeler ce qu'est l'espace d'adressage du MIPS et dîtes ce que signifie « une adresse X est mappée en mémoire ».
Dîtes si une adresse X mappée en mémoire est toujours accessible (en lecture ou en écriture) quelque soit le mode d'exécution du MIPS. - Le MIPS propose des registres à usage général (GPR General Purpose Register) pour les calculs ($0 à $31). Le MIPS propose un deuxième banc de registres à l'usage du système d'exploitation, ce sont les registres système (dit du coprocesseur 0).
Comment sont-ils numérotés? Chaque registre porte un nom correspondant à son usage, quels sont ceux que vous connaissez: donner leur nom, leur numéro et leur rôle? Peut-on faire des calculs avec des registres? Quelles sont les instructions qui permettent de les manipuler? - Le registre status est composé de plusieurs champs de bits qui ont chacun une fonction spécifique.
Décrivez le contenu du registre status et le rôle des bits de l'octet 0 (seulement les bits vus en cours). - Le registre cause est contient la cause d'appel du kernel.
Dites à quel endroit est stockée cette cause et donnez la signification des codes 0, 4 et 8 - Le registre
C0_EPCest un registre 32 bits qui contient une adresse. Vous devriez l'avoir décrit dans la question 2.
Expliquez pourquoi ce doit être l'adresse de l'instruction qui provoque une exception qui doit être stockée dansC0_EPC? - Nous avons vu trois instructions ne sont pas utilisable lorsque le MIPS est en mode kernel, lesquelles? Que font-elles?
Est-ce que l'instructionsyscallpeut-être utilisée en mode user? - Quelle est l'adresse d'entrée dans le noyau?
- Que se passe-t-il quand le MIPS entre dans le noyau, après l'exécution de l'instruction
syscall? - Quelle instruction utilise-t-on pour sortir du noyau et entrer dans l'application ? Dîtes précisément ce que fait cette instruction dans le MIPS?
A2. Langage C pour la programmation système
La programmation en C, vous connaissez, mais quand on programme pour le noyau, c'est un peu différent. Il y a des éléments de syntaxe ou des besoins spécifiques.
Questions
- En assembleur, vous utilisez les sections prédéfinies
.dataet.textpour placer respectivement les data et le code ou alors vous pouvez créer vos propres sections avec la directive.section(nous avons utilisé cette possibilité pour la section.boot). Il est aussi possible d'imposer ou de créer des sections en langage C avec le mot clé__attribute__. Ce mot clé du C permet de demander certains comportements au compilateur. Il y a en a beaucoup (si cela vous intéresse vous pouvez regarder dans la doc de GCC sur les attributs. En cours, nous avons vu un attribut permettant de désigner ou créer une section dans laquelle est mise la fonction concernée. Quelle était la syntaxe de cet attribut (regardez sur le slide 37). - En C, vous savez que les variables globales sont toujours initialisées, soit explicitement dans le programme lui-même, soit implicitement à la valeur
0. Les variables globales initialisées sont placées dans la section.data(ou plutôt dans l'une des sectionsdata:.data,.sdata,.rodata, etc.) et elles sont présentes dans le fichier objet (.o) produit pas le compilateur. En revanche, les variables globales non explicitement initialisées ne sont pas présentes dans le fichier objet. Ces dernières sont placées dans un segment de la famille.bss. C'est grâce au fichier ldscript que nous pouvons mapper l'ensemble des segments en mémoire.
Pour pouvoir initialiser à0les segmentsbsspar programme, il nous faut connaître l'adresse de début et de fin en mémoire. Le code ci-dessous est le fichier ldscript du kernelkernel.ld(nous avons retier les commentaires pour la circonstance.
Expliquez ce que font les lignes 11, 12 et 15.1 SECTIONS 2 { 3 .boot : { 4 *(.boot) 5 } > boot_region 6 .ktext : { 7 *(.text*) 8 } > ktext_region 9 .kdata : { 10 *(.*data*) 11 . = ALIGN(4); 12 __bss_origin = .; 13 *(.*bss*) 14 . = ALIGN(4); 15 __bss_end = .; 16 } > kdata_region 17 }
- Nous connaissons les adresses des registres de périphériques. Ces adresses sont déclarées dans le fichier ldscript
kernel.ld. Ci-après, nous avons la déclaration de la variable de ldscript__tty_regs_map. Cette variable est aussi utilisable dans les programmes C, mais pour être utilisable par le compilateur C, il est nécessaire de lui dire quel type de variable c'est. Est-ce une adresse d'entier? Est-ce une adresse de tableau d'entiers? Ou encore, est-ce une structure?
Dans le fichierkernel.ld:Dans le fichier__tty_regs_map = 0xd0200000 ; /* tty's registers map, described in devices.h */
harch.c:À quoi servent les mots clés12 struct tty_s { 13 int write; // tty's output address 14 int status; // tty's status address something to read if not null) 15 int read; // tty's input address 16 int unused; // unused address 17 }; 18 19 extern volatile struct tty_s __tty_regs_map[NTTYS];
externetvolatile?
Si NTTYS est une macro dont la valeur est 2, quelle est l'adresse en mémoire__tty_regs_map[1].read? - Certaines parties du noyau sont en assembleur. Il y a au moins les toutes premières instructions du code de boot (démarrage de l'ordinateur) et l'entrée dans le noyau après l'exécution d'un syscall. Dans ce dernier cas, le gestionnaire de syscall écrit en assembleur a besoin d'appeler une fonction écrite en langage C. Le gestionnaire de syscall trouve l'adresse de la fonction C qu'il doit appeler puis il place cette adresse dans un registre, par exemple
$2. Il suffit qu'il exécute l'instructionjal $2pour appeler la fonction. Que doivent contenir les registres$4à$7et comment doit-être la pile? - Vous avez appris à écrire des programmes assembleur, mais parfois il est plus simple, voire il est nécessaire de mélanger le code C et le code assembleur. Dans l'exemple ci-dessous, nous voyons comment la fonction
kinit()procède pour entrer dans la fonction placée à l'adresse__crt0définie dans le fichierkernel.ld. Remarquez la syntaxe, icivolatilepermet de dire au compilateur d'insérer le code tel que sans le modifier. Notez aussi l'absence de,entre les chaînes de caractères. Le premier argument de__asm__est une chaîne de caractères unique dans laquelle les instructions sont séparées par de\n. Il peut y avoir d'autres arguments, nous ne les verrons pas.
Dans quelle section se trouve l'adresse__crt0? Combien vaut-elle? Est-ce que cette valeur est imposée par le processeur MIPS comme l'adresse de boot ou d'entrée dans le kernel? Quelle fonction est à cette adresse? Pourquoi doit-on écrire ce code en assembleur?9 void kinit (void) 10 { 11 kprintf (0, banner); 12 13 // put bss sections to zero. bss contains uninitialised global variables 14 extern int __bss_origin; // first int of bss section 15 extern int __bss_end; // first int of above bss section 16 for (int *a = &__bss_origin; a != &__bss_end; *a++ = 0); 17 18 // this code allows to exit the kernel to go to user code 19 __asm__ volatile ( "la $26, __text_origin \n" // get first address of user code 20 "mtc0 $26, $14 \n" // put it in c0_EPC 21 "li $26, 0b00010010 \n" // next status [UM,0,ERL,EXL,IE] 22 "mtc0 $26, $12 \n" // UM <- 1, IE <- 0, EXL <- 1 23 "la $29, __data_end \n" // define new user stack pointer 24 "eret \n"); // j EPC and EXL <- 0 25 }
- Dans le code C de la question précédente, à quoi servent les lignes 12 à 16? Pourquoi faire des déclarations
extern?
A3. Passage entre les modes kernel et user
Le noyau et l'application sont deux exécutables compilés indépendamment mais pas qui ne sont pas indépendants. Vous savez déjà que l'application appelle les services du noyau avec l'instruction syscall, mais comment ça se passe vraiment depuis le code C? Certaines questions sont proches de celles déjà posées, c'est volontaire.
Questions
- Comment imposer le placement d'adresse d'une fonction ou d'une variable en mémoire?
- Dans la question A2.5, nous avons vu comment la fonction
kinitappelle la fonction__start()grâce à un bout de code en assembleur. Nous allons voir maintenant quelles sont les conditions de cet appel. Dans le code de la question A2.5,$26est un registre de travail pour le kernel. Quels sont les autres registres modifiés? Expliquez pour chacun la valeur affectée. - Que faire avant et après l'exécution de la fonction
main()du point de vue de l'initialisation? - Nous avons vu que le noyau est sollicité par des événements, quels sont-ils?Quel est le comportement exact de l'instruction
syscall? Comment le noyau fait-il pour connaître la cause de son appel? $26et$27sont deux registres temporaires que le noyau se réserve pour faire des calculs sans qu'il ait besoin de les sauvegarder dans la pile. Ce ne sont pas des registres système commec0_srouc0_epc. En effet, l'usage des registres$26et$27par l'utilisateur ne provoque pas d'exception du MIPS. Toutefois si le noyau est appelé alors il modifie ces registres et donc l'utilisateur perd leur valeur. Le code assembleur ci-après contient les instructions exécutées par le noyau, quelle que soit la cause. Les commentaires présents dans le code ont été volontairement retirés (ils sont dans les fichiers du TP). La section.kentryest placée à l'adresse0x80000000par l'éditeur de lien. La directive.org(ligne 16) permet de déplacer le pointeur de remplissage de la section courante du nombre d'octets donnés en argument, ici0x180. Pouvez-vous dire pourquoi ? Expliquer les lignes 25 à 28.
kernel/hcpu.S15 .section .kentry,"ax" 16 .org 0x180 22 23 kentry: 24 25 mfc0 $26, $13 26 andi $26, $26, 0x3C 27 li $27, 0x20 28 bne $26, $27, not_syscall
- 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 fichierkernel/hcpu.Sque nous allons observer. Pour vous aider dans la compréhension de ce code, vous devez imaginer que l'instructionsyscallest un peu comme un appel de fonction. Ce code utilise un tableau de pointeurs de fonctions nommésyscall_vectordéfinit dans le fichierkernel/ksyscalls.c. Les lignes36à43sont 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 lige44et quelle conséquence cela a? Que font les lignes46à51? Et enfin que font les lignes53à59sans détailler ligne à ligne.
common/syscalls.h1 #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.cvoid *syscall_vector[] = { [0 ... SYSCALL_NR - 1] = unknown_syscall, [SYSCALL_EXIT] = exit, [SYSCALL_TTY_READ] = tty_read, [SYSCALL_TTY_WRITE] = tty_write, [SYSCALL_CLOCK] = clock, };
kernel/hcpu.S34 ksyscall: 35 36 addiu $29, $29, -8*4 37 mfc0 $27, $14 38 mfc0 $26, $12 39 addiu $27, $27, 4 40 sw $31, 7*4($29) 41 sw $27, 6*4($29) 42 sw $26, 5*4($29) 43 sw $2, 4*4($29) 44 mtc0 $0, $12 45 46 la $26, syscall_vector 47 andi $2, $2, SYSCALL_NR-1 48 sll $2, $2, 2 49 addu $2, $26, $2 50 lw $2, 0($2) 51 jalr $2 52 53 lw $26, 5*4($29) 54 lw $27, 6*4($29) 55 lw $31, 7*4($29) 56 mtc0 $26, $12 57 mtc0 $27, $14 58 addiu $29, $29, 8*4 59 eret
A4. Génération du code exécutable
Pour simuler le logiciel, il faut produire deux exécutables. Nous utilisons, ici, un Makefile hiérarchique et des règles explicites. Cela sort du cadre de l'architecture, mais vous avez besoin de ce savoir-faire pour comprendre le code, alors allons-y.
Questions
- Rappelez là quoi sert un Makefile?
- Vous n'allez pas à avoir à écrire un Makefile complètement, toutefois vous allez devoir les modifier en ajoutant des règles. Nous avons vu brièvement la syntaxe utilisée dans les Makefiles de ce TP au cours n°1. Les lignes qui suivent sont des extraits du premier Makefile. Dans cet extrait, quelles sont la cible finale, les cibles intermédiaires et les sources? A quoi servent les variables automatiques de make? Dans ces deux règles, donnez-en la valeur.
kernel.x : kernel.ld obj/hcpu.o obj/kinit.o obj/klibc.o obj/harch.o $(LD) -o $@ -T $^ $(OD) -D $@ > $@.s obj/hcpu.o : hcpu.S hcpu.h $(CC) -o $@ $(CFLAGS) $< $(OD) -D $@ > $@.s
- Dans le TP, à partir de la deuxième étape, nous avons trois répertoires de sources
kernel,ulibetuapp. Chaque répertoire contient une fichierMakefiledifférent destiné à produire une cible différente grâce à une règle nomméecompil, c.-à-d. si vous tapezmake compildans un de ces répertoires, cela compile les sources locales.
Il y a aussi un Makefile dans le répertoire racine4_libc. Dans ce dernier Makefile, une des règles est destinée à la compilation de l'ensemble des sources dans les trois sous-répertoires. Cette règle appelle récursivement la commandemakeen donnant en argument le nom du sous-répertoire où descendre :make -C <répertoire> [cible]est équivalent àcd <répertoire>; make [cible] ; cd ..
Ecrivez la règlecompildu fichier4_libc/Makefile.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 ├── kernel ────────── Répertoire des fichiers composant le kernel │ └── Makefile : description des actions possibles sur le code kernel : compilation et nettoyage ├── uapp ──────────── Répertoire des fichiers de l'application user seule │ └── 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 └── Makefile : description des actions possibles sur le code user : compilation et nettoyage
B. Travaux pratiques
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. 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 $AS5/tp2/, ouvrez un terminal et allez-y. Dans ce répertoire, vous avez 4 sous-répertoires et un Makefile. Le fichier $AS5/tp2/Makefile permet de faire le ménage en appelant les Makefiles des sous-répertoires avec la cible clean.
B1. Ajout d'une bibliothèque de fonctions standards pour le kernel (klic)
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() ├── hcpu.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
- Ouvrez le fichier Makefile, En ouvrant tous les fichiers dessiner le graphe de dépendance de
kernel.xvis-à-vis de ses sources? - Dans quel fichier se trouvent les codes dépendant du MIPS ?
Exercices
- Le numéro du processeur est les 12 bits de poids faible du registre $15 du coprocesseur système (à côté des registres
c0_epc,c0_sr, etc.). Ajoutez de la fonctionint cpuid(void)qui lit le registre$15du coprocesseur système et qui rend un entier contenant juste les 12 bits de poids faible.
Vous pouvez vous inspirez fortement de la fonctionclock(). Comme il n'y a qu'un seul processeur dans cette architecture,cpuidrend0.
Ecrivez un programme de test.
B2. 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 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'adressage réservées aux 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()
│ ├── hcpu.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 : crt0()
├── 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
- Combien de fichiers de type ldscript avons-nous ?
- Dans quel fichier se trouve la première fonction de l'application et comment s'appelle-t-elle?
- Quelle est la fonction du noyau qui appelle cette fonction et dans quel ?
- 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()
B3. 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_WRITE, SYSCALL_EXIT sont définis dans un .h communs 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
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()
│ ├── hcpu.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
│ ├── 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 : crt0()
├── 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
- Dans quel fichier se trouve la définition des numéros de services tels que
SYSCALL_EXIT? - 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 ? - Dans quel fichier se trouve le gestionnaire de syscalls ?
Exercice
- Vous allez ajouter un appel système nommé
SYSCALL_CPUIDqui rend le numéro du processeur. Nous allons lui attribuer le numéro 4 (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: pour ajouter le numéro de servicekernel/ksyscall.c: pour modifier le vecteur de syscallkernel/hcpu.S: pour ajouter la fonctionint cpuid(void)(la même que celle demandé en B.1)kernel/hcpu.h: pour déclarer le prototype deint cpuid(void)(comme pour B.1)
B4. Ajout de la librairie C
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 de 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 : le code de l'application et le code de la librairie et nous allons répartir le code dans deux répertoire uapp pour les fichiers de l'application et ulib pour les fichiers qui ne sont pas l'application, c'est-à-dire la libc, mais aussi le fichier ldscript et le fichier crt0.c.
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()
│ ├── hcpu.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
│ ├── 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
├── 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 : crt0()
├── 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
- Pour ce petit système, quel fichier sont placés les prototypes de la libc? Est-ce ainsi pour POSIX sur LINUX?
Exercice
- Vous allez juste ajouter la fonction
int cpuid()dans la librairie
