Le petit livre sur le développement d'un OS

Le noyau de l'OS et ce livre ont été produits dans le cadre d'un cours individuel avancé à l'Institut royal de technologie(2) de Stockholm. Les auteurs avaient déjà suivi des cours en théorie système, mais avaient une expérience pratique limitée dans le développement du noyau du système d'exploitation. Afin d'obtenir une expérience personnelle plus détaillée et une compréhension approfondie de la façon dont la théorie des précédents cours système fonctionne dans la pratique, les auteurs ont décidé de créer un nouveau cours, qui a porté sur le développement d'un petit système d'exploitation. Un autre objectif du cours était d'écrire un tutoriel complet sur la façon de développer un petit OS à partir de zéro, et ce petit livre en est le résultat.

L'architecture x86 est depuis longtemps l'une des architectures matérielles les plus courantes. Ce ne fut pas un choix difficile que d'opter pour l'architecture x86, avec sa grande communauté, de nombreux documents de référence et des émulateurs matures, comme cible de l'OS. La documentation et l'information concernant les détails du matériel avec lequel nous avons dû travailler ne furent pas toujours faciles à trouver ou à comprendre, en dépit (ou peut-être à cause) de l'âge vénérable de cette architecture.

Le système d'exploitation a été développé en à peu près six semaines de travail à temps plein. La mise en œuvre a été réalisée en plusieurs petites étapes. Après chaque étape, le système d'exploitation a été testé manuellement. En développant de cette manière incrémentale et itérative, il est souvent plus facile de trouver tout éventuel bogue introduit, puisque seule une petite partie du code a changé depuis le dernier état stable connu du code. Nous encourageons le lecteur à travailler d'une manière similaire.

Pendant les six semaines de développement, presque chaque ligne de code a été écrite par les auteurs ensemble (cette façon de travailler est parfois appelée programmation en binôme). Notre conviction est que nous avons réussi à éviter un grand nombre de bogues grâce à ce style de développement, mais cela est difficile à établir scientifiquement.

Le lecteur de ce livre doit être à l'aise avec UNIX/Linux, la programmation système, le langage C et les systèmes informatiques en général (comme la notation hexadécimale(3)). Ce livre pourrait être une façon de commencer l'apprentissage de ces choses, mais ce sera plus difficile, et le développement d'un système d'exploitation est déjà difficile en soi. Les moteurs de recherche et autres tutoriels sont souvent utiles si vous êtes bloqué.

Nous tenons à remercier la communauté OSDev(4) pour leur superbe wiki et ses membres serviables, et James Malloy pour son excellent tutoriel de développement du noyau(5). Nous aimerions également remercier notre superviseur, Torbjörn Granlund, pour ses questions pertinentes et les discussions intéressantes.

La plus grande partie de la mise en forme CSS du livre est basée sur le travail de Scott Chacon pour le livre Pro Git, http://progit.org/.

Nous sommes très reconnaissants pour les correctifs que les gens nous envoient. Les utilisateurs suivants ont tous contribué à ce livre :

• alexschneider
• Avidanborisov
• nirs
• kedarmhaswade
• vamanea
• ansjob

Ce livre est hébergé sur Github - si vous avez des suggestions, des commentaires ou des corrections, forkez simplement le livre, rédigez vos changements et envoyez-nous une pull request. Nous serons heureux d'intégrer tout ce qui rend ce livre meilleur.

Si vous rencontrez des problèmes lors de la lecture du livre, veuillez vérifier les problèmes sur Github pour trouver de l'aide : https://github.com/littleosbook/littleosbook/issues.

Tout le contenu est sous licence Creative Commons Attribution Non Commercial Share Alike 3.0, http://creativecommons.org/licenses/by-nc-sa/3.0/us/. Les exemples de code sont dans le domaine public - utilisez-les comme vous voulez. Les références à ce livre sont toujours reçues chaleureusement.

2-1-1. Configuration rapide▲

sudo apt-get install build-essential nasm genisoimage bochs bochs-sdl

2-1-2. Langages de programmation▲

    __attribute__((packed))

2-1-3. Système d'exploitation hôte▲

2-1-4. Système de compilation▲

2-1-5. Machine virtuelle▲

L'amorçage ou séquence de boot d'un système d'exploitation consiste à transférer le contrôle au long d'une chaîne de petits programmes, chacun d'entre eux étant plus « puissant » que le précédent, et dans laquelle le système d'exploitation est le dernier « programme » de la liste. La figure suivante donne un exemple de processus d'amorçage :

2-2-1. BIOS▲

2-2-2. Le chargeur d'amorçage (bootloader)▲

2-2-3. Le système d'exploitation▲

Cette section décrit comment mettre en œuvre le plus petit OS qui puisse être utilisé avec GRUB. La seule chose que l'OS va faire est d'écrire 0xCAFEBABE dans le registre eax (probablement, la plupart des gens n'appelleraient même pas cela un système d'exploitation).

2-3-1. Compiler le système d'exploitation▲

global loader                      ; le symbole d'entrée pour ELF

NOMBRE_MAGIQUE equ 0x1BADB002      ; définit la constante nombre magique
DRAPEAUX       equ 0x0             ; drapeaux multiboot
CHECKSUM       equ -NOMBRE_MAGIQUE ; calcule la somme de contrôle
                                   ; (nombre magique + somme de contrôle + drapeaux doit être égal à 0)

section .text:                     ; début de la section texte (code)
align 4                            ; le code doit être aligné à 4 octets
    dd NOMBRE_MAGIQUE              ; écrit le nombre magique en code machine,
    dd DRAPEAUX                    ; les drapeaux,
    dd CHECKSUM                    ; et la somme de contrôle
loader:                            ; l'étiquette du chargeur (définie comme point d'entrée dans le script de l'éditeur de liens)
    mov eax, 0xCAFEBABE            ; place le nombre 0xCAFEBABE dans le registre eax
.loop:
    jmp .loop                      ; boucle infinie

nasm -f elf32 loader.s

2-3-2. Éditer les liens du noyau▲

ENTRY(loader)                /* le nom de l'étiquette du point d'entrée */

SECTIONS {
    . = 0x00100000;          /* le code doit être chargé à 1 Mo */

    .text ALIGN (0x1000) :   /* alignement à 4 ko */
    {
        *(.text)             /* toutes les sections texte de tous les fichiers */
    }

    .rodata ALIGN (0x1000) : /* alignement à 4 ko */
    {
        *(.rodata*)          /* toutes les sections de données en lecture seule, de tous les fichiers */
    }

    .data ALIGN (0x1000) :   /* alignement à 4 ko */
    {
        *(.data)             /* toutes les sections de données, de tous les fichiers */
    }

    .bss ALIGN (0x1000) :    /* alignement à 4 ko */
    {
        *(COMMON)            /* toutes les sections COMMON de tous les fichiers */
        *(.bss)              /* toutes les sections bss de tous les fichiers */
    }
}

ld -T link.ld -melf_i386 loader.o -o kernel.elf

2-3-3. Obtenir GRUB▲

2-3-4. Créer une image ISO▲

mkdir -p iso/boot/grub            # crée la structure du répertoire
cp stage2_eltorito iso/boot/grub/ # copie le chargeur d'amorçage
cp kernel.elf iso/boot/           # copie le noyau

default=0
timeout=0

title os
kernel /boot/kernel.elf

    iso
    |-- boot
      |-- grub
      | |-- menu.lst
      | |-- stage2_eltorito
      |-- kernel.elf

genisoimage -R                              \
            -b boot/grub/stage2_eltorito    \
            -no-emul-boot                   \
            -boot-load-size 4               \
            -A os                           \
            -input-charset utf8             \
            -quiet                          \
            -boot-info-table                \
            -o os.iso                       \
            iso

2-3-5. Exécuter Bochs▲

megs:            32
display_library: sdl
romimage:        file=/usr/share/bochs/BIOS-bochs-latest
vgaromimage:     file=/usr/share/bochs/VGABIOS-lgpl-latest
ata0-master:     type=cdrom, path=os.iso, status=inserted
boot:            cdrom
log:             bochslog.txt
clock:           sync=realtime, time0=local
cpu:             count=1, ips=1000000

bochs -f bochsrc.txt -q

cat bochslog.txt

• Gustavo Duarte a écrit un article approfondi sur ce qui se passe réellement quand un ordinateur x86 s'amorce, http://duartes.org/gustavo/blog/post/how-computers-boot-up
• Gustavo continue à décrire ce que fait le noyau dans les stades très précoces http://duartes.org/gustavo/blog/post/kernel-boot-process
• Le wiki de OSDev contient également un bel article sur l'amorçage d'un ordinateur x86 : http://wiki.osdev.org/Boot_Sequence

Une condition préalable pour l'utilisation du C est l'existence d'une pile, puisque tous les programmes non triviaux en C en utilisent une. La mise en place d'une pile n'est pas plus difficile que de faire pointer le registre esp vers la fin d'une zone de mémoire libre (rappelez-vous que sur l'architecture x86, la pile se développe vers les adresses inférieures) qui est correctement alignée (l'alignement à 4 octets est recommandé d'un point de vue de la performance).

Nous pourrions faire pointer esp vers une zone aléatoire dans la mémoire puisque, jusqu'à présent, dans la mémoire ne se trouvent que GRUB, BIOS, le noyau du système d'exploitation et certaines E/S mappées en mémoire. Mais ce n'est pas une bonne idée, car nous ignorons la taille de la mémoire disponible, ou si la zone vers laquelle esp pointerait est utilisée par autre chose. Il vaut mieux réserver une partie de mémoire non initialisée dans la section bss du fichier ELF du noyau. Il est préférable d'utiliser la section bss à la place de la section data, afin de réduire la taille de l'exécutable de l'OS. Puisqu'il comprend ELF, GRUB va allouer lors du chargement de l'OS tout espace mémoire réservé dans la section bss.

La pseudo-instruction resb(24) de NASM peut être utilisée pour déclarer des données non initialisées :

KERNEL_STACK_SIZE equ 4096        ; taille de la pile en octets

section .bss
align 4                           ; alignement à 4 octets
kernel_stack:                     ; étiquette pointant vers le début de la mémoire
    resb KERNEL_STACK_SIZE        ; réserve la pile pour le noyau

Il n'y a pas lieu de se soucier de l'utilisation d'emplacements de mémoire non initialisés pour la pile, car il est impossible de lire un emplacement de la pile qui n'a pas été écrit (à moins de bidouiller manuellement le pointeur de la pile). Un programme (correct) ne peut pas prélever un élément de la pile sans l'y avoir préalablement mis. Par conséquent, les emplacements de mémoire de la pile auront toujours été forcément écrits avant d'être lus.

Le pointeur de la pile est alors configuré en faisant pointer esp vers la fin de la mémoire kernel_stack :

mov esp, kernel_stack + KERNEL_STACK_SIZE   ; fait pointer esp vers le début de la
                                            ; pile (fin de la zone de mémoire)

L'étape suivante est d'appeler une fonction C à partir du code en assembleur. Il existe de nombreuses conventions différentes pour faire cela(25). Ce livre utilise la convention d'appel cdecl, puisque c'est celle utilisée par GCC. La convention d'appel cdecl stipule que les arguments d'une fonction doivent être passés via la pile (sur x86). Les arguments de la fonction doivent être déposés sur la pile de droite à gauche, c'est-à-dire que l'on commence par l'argument le plus à droite. La valeur de retour de la fonction est placée dans le registre eax. Le code suivant montre un exemple :

/* La fonction C */
int somme_de_trois(int arg1, int arg2, int arg3)
{
    return arg1 + arg2 + arg3;
}

; Le code assembleur 
external somme_de_trois ; la fonction somme_de_trois est définie ailleurs

push dword 3            ; arg3
push dword 2            ; arg2
push dword 1            ; arg1
call somme_de_trois     ; appelle la fonction, le résultat sera en eax

3-2-1. Compacter les structures▲

Bit:     | 31     24 | 23          8 | 7     0 |
Contenu: | index     | adresse       | config  |

struct exemple {
    unsigned char config;   /* bit 0 - 7   */
    unsigned short adresse; /* bit 8 - 23  */
    unsigned char index;    /* bit 24 - 31 */
};

struct exemple {
    unsigned char config;   /* bit 0 - 7   */
    unsigned short adresse; /* bit 8 - 23  */
    unsigned char index;    /* bit 24 - 31 */
} __attribute__((packed));

Lors de la compilation du code C pour le système d'exploitation, il faut utiliser un certain nombre d'options de compilation spécifiques de GCC, parce que le code C ne doit pas supposer la présence d'une bibliothèque standard, puisqu'il n'y a aucune bibliothèque standard disponible pour notre OS. Pour plus d'informations sur ces options, voir le manuel de GCC.

Les options utilisées pour compiler le code C sont :

    -m32 -nostdlib -nostdinc -fno-builtin -fno-stack-protector
    -nostartfiles  -nodefaultlibs

Comme toujours lors de l'écriture des programmes en C, nous recommandons d'activer tous les avertissements et de traiter les avertissements comme des erreurs :

    -Wall -Wextra -Werror

Maintenant, vous pouvez créer dans un fichier appelé kmain.c une fonction kmain que vous appelez à partir de loader.s. À ce stade, kmain n'aura probablement besoin d'aucun argument (mais ce sera le cas dans les chapitres suivants).

C'est probablement aussi le bon moment pour mettre en place des outils de compilation pour faciliter la compilation et les tests d'exécution de l'OS. Nous vous recommandons d'utiliser make du GNU, mais beaucoup d'autres systèmes de compilation sont disponibles. Un simple Makefile pour l'OS pourrait ressembler à l'exemple suivant :

OBJECTS = loader.o kmain.o
CC = gcc
CFLAGS = -m32 -nostdlib -nostdinc -fno-builtin -fno-stack-protector \
         -nostartfiles -nodefaultlibs -Wall -Wextra -Werror -c
LDFLAGS = -T link.ld -melf_i386
AS = nasm
ASFLAGS = -f elf

all: kernel.elf

kernel.elf: $(OBJECTS)
    ld $(LDFLAGS) $(OBJECTS) -o kernel.elf

os.iso: kernel.elf
    cp kernel.elf iso/boot/kernel.elf
    genisoimage -R                              \
                -b boot/grub/stage2_eltorito    \
                -no-emul-boot                   \
                -boot-load-size 4               \
                -A os                           \
                -input-charset utf8             \
                -quiet                          \
                -boot-info-table                \
                -o os.iso                       \
                iso

run: os.iso
    bochs -f bochsrc.txt -q

%.o: %.c
    $(CC) $(CFLAGS)  $< -o $@

%.o: %.s
    $(AS) $(ASFLAGS) $< -o $@

clean:
    rm -rf *.o kernel.elf os.iso

Le contenu de votre répertoire de travail devrait ressembler à ce qui suit :

    .
    |-- bochsrc.txt
    |-- iso
    |   |-- boot
    |     |-- grub
    |       |-- menu.lst
    |       |-- stage2_eltorito
    |-- kmain.c
    |-- loader.s
    |-- Makefile

Vous devriez maintenant être en mesure de démarrer le système d'exploitation par une simple commande make run, qui va compiler le noyau et le démarrer dans Bochs (comme défini dans le Makefile ci-dessus).

Le livre Le langage C, Deuxième édition (Dunod), de Brian Kernighan et Dennis Ritchie est idéal pour apprendre tous les aspects du C.

Il y a généralement deux façons différentes d'interagir avec le matériel, les E/S mappées en mémoire et les ports d'E/S.

Si le matériel utilise les E/S mappées en mémoire, alors vous pouvez écrire à une adresse mémoire spécifique et le matériel sera mis à jour avec les nouvelles données. Un exemple est représenté par le tampon de trame, qui sera décrit plus en détail plus tard. Par exemple, si vous écrivez la valeur 0x410F à l'adresse 0x000B8000, vous verrez la lettre A en blanc sur un fond noir (voir la section sur le tampon de trameLe tampon de trame pour plus de détails).

Si le matériel utilise des ports E/S, alors les instructions assembleur out et in doivent être utilisées pour communiquer avec le matériel. L'instruction out prend deux paramètres : l'adresse du port d'E/S et les données à envoyer. L'instruction in prend un seul paramètre, l'adresse du port d'E/S, et retourne les données à partir du matériel. On peut penser aux ports d'E/S comme communiquant avec le matériel de la même manière que vous communiquez avec un serveur en utilisant les sockets. Le curseur (le rectangle clignotant) du tampon de trame est un exemple du matériel sur un PC contrôlé via les ports d'E/S.

Le tampon de trame est un dispositif matériel qui est capable d'afficher à l'écran le contenu de la mémoire tampon. Il dispose de 80 colonnes et 25 lignes, et les indices des lignes et des colonnes commencent à 0 (les lignes sont donc numérotées de 0 à 24).

4-2-1. Écrire du texte▲

Bit :     | 15 14 13 12 11 10 9 8 | 7 6 5 4 | 3 2 1 0 |
Contenu : | ASCII                 |Av.-plan | Ar.-plan|

mov [0x000B8000], 0x4128

0x000B8000 + 16 = 0x000B8010

tt[0] = 'A';
tt[1] = 0x28;

/** tt_ecrire_cellule :
*  Écrit un caractère avec l'avant-plan et l'arrière-plan donnés à la position i
*  dans le tampon de trame.
*
*  @param i  L'emplacement dans le tampon de trame
*  @param c  Le caractère
*  @param fg La couleur de l'avant-plan
*  @param bg La couleur de l'arrière-plan
*/
void tt_ecrire_cellule(unsigned int i, char c, unsigned char fg, unsigned char bg)
{
    tt[i] = c;
    tt[i + 1] = ((fg & 0x0F) << 4) | (bg & 0x0F)
}

#define TT_VERT       2
#define TT_GRIS_FONCE 8

tt_ecrire_cellule(0, 'A', TT_VERT, TT_GRIS_FONCE);

4-2-2. Déplacer le curseur▲

out 0x3D4, 14      ; 14 dit au tampon de trame d'attendre les 8 bits supérieurs de la position
out 0x3D5, 0x00    ; envoyer les 8 bits supérieurs de 0x0050
out 0x3D4, 15      ; 15 dit au tampon de trame d'attendre les 8 bits inférieurs de la position
out 0x3D5, 0x50    ; envoyer les 8 bits inférieurs de 0x0050

global outb           ; rend l'étiquette outb visible en dehors de ce fichier

; outb - envoie un octet vers un port E/S
; pile : [esp + 8] l'octet de données
;        [esp + 4] le port E/S
;        [esp    ] l'adresse de retour
outb:
    mov al, [esp + 8] ; déplace les données à envoyer dans le registre al
    mov dx, [esp + 4] ; déplace l'adresse du port E/S dans le registre dx 
    out dx, al        ; envoie les données vers le port E/S
    ret               ; retour vers la fonction appelante

#ifndef INCLUDE_IO_H
#define INCLUDE_IO_H

/** outb:
 *  Envoie les données vers le port E/S donné. Défini en io.s
 *
 *  @param port Le port E/S vers lequel envoyer les données
 *  @param data Les données à envoyer vers le port E/S
 */
void outb(unsigned short port, unsigned char data);

#endif /* INCLUDE_IO_H */

#include "io.h"

/* Les ports d'E/S */
#define TT_PORT_COMMANDE        0x3D4
#define TT_PORT_DATA            0x3D5

/* Les commandes du port d'E/S */
#define TT_COMMANDE_OCTET_SUP    14
#define TT_COMMANDE_OCTET_INF    15

/** tt_deplace_curseur:
 *  Déplace le curseur du tampon de trame à la position donnée
 *
 *  @param pos La nouvelle position du curseur
 */
void tt_deplace_curseur(unsigned short pos)
{
    outb(TT_PORT_COMMANDE, TT_COMMANDE_OCTET_SUP);
    outb(TT_PORT_DATA,    ((pos >> 8) & 0x00FF));
    outb(TT_PORT_COMMANDE, TT_COMMANDE_OCTET_INF);
    outb(TT_PORT_DATA,    pos & 0x00FF);
}

4-2-3. Le pilote▲

int write(char *buf, unsigned int len);

Le port série (30) est une interface pour la communication entre dispositifs matériels. Même s'il est disponible sur la quasi-totalité des cartes mères, il est de nos jours moins souvent disponible à l'utilisateur sous la forme d'un connecteur DE-9 (à 9 broches). Le port série est facile à utiliser et, surtout, peut être utilisé comme un outil de journalisation dans Bochs. Si un ordinateur a un support pour un port série, alors il a généralement le support pour plusieurs ports série ; mais nous en utiliserons un seul, car nous allons utiliser les ports série uniquement pour la journalisation. En outre, nous allons utiliser les ports série uniquement pour la sortie, pas pour l'entrée. Les ports série sont complètement contrôlés via les ports E/S.

4-3-1. Configurer le port série▲

4-3-2. Configurer la ligne▲

#include "io.h" /* io.h est implémenté dans la section « Déplacer le curseur » */

/* Les ports E/S */

/* Tous les ports E/S sont calculés par rapport au port de données.  Cela, parce que
 * tous les ports série (COM1, COM2, COM3, COM4) ont leurs ports dans le même
 * ordre, mais ils commencent à des valeurs différentes.
 */

#define SERIE_COM1_BASE                0x3F8      /* le port COM1 base */

#define SERIE_DATA_PORT(base)           (base)
#define SERIE_FIFO_COMMAND_PORT(base)   (base + 2)
#define SERIE_LIGNE_COMMAND_PORT(base)  (base + 3)
#define SERIE_MODEM_COMMAND_PORT(base)  (base + 4)
#define SERIE_LIGNE_STATUS_PORT(base)   (base + 5)

/* Les commandes de port E/S */

/* SERIE_LIGNE_ACTIVER_DLAB:
 * Dit au port série d'attendre en premier les 8 bits les plus élevés sur le port de données,
 * puis les 8 bits inférieurs suivront
 */
#define SERIE_LIGNE_ACTIVER_DLAB         0x80

/** serie_configurer_baud_rate:
 *  Définit la vitesse d'envoi des données. La vitesse par défaut d'un port série
 *  est de 115200 bits/s. L'argument est un diviseur de ce nombre, alors la vitesse
 *  résultante devient (115200 / diviseur) bits/s.
 *
 *  @param com       Le port COM à configurer
 *  @param diviseur  Le diviseur
 */
void serie_configurer_baud_rate(unsigned short com, unsigned short diviseur)
{
    outb(SERIE_LIGNE_COMMAND_PORT(com),
         SERIE_LIGNE_ACTIVER_DLAB);
    outb(SERIE_DATA_PORT(com),
         (divisor >> 8) & 0x00FF);
    outb(SERIE_DATA_PORT(com),
         divisor & 0x00FF);
}

Bit :     | 7 | 6 | 5 4 3 | 2 | 1 0 |
Contenu : | d | b | prty  | s | dl  |

/** configurer_ligne_serie :
 *  Configure la ligne du port série donné. Le port est configuré pour avoir une
 *  longueur des données de 8 bits, aucun bit de parité, un bit d'arrêt et le
 *  contrôle d'interruption désactivé.
 *
 *  @param com  Le port série à configurer
 */
void configurer_ligne_serie(unsigned short com)
{
    /* Bit :     | 7 | 6 | 5 4 3 | 2 | 1 0 |
     * Contenu : | d | b | prty  | s | dl  |
     * Valeur :  | 0 | 0 | 0 0 0 | 0 | 1 1 | = 0x03
     */
    outb(SERIE_LIGNE_COMMAND_PORT(com), 0x03);
}

4-3-3. Configurer les tampons▲

Bit :     | 7 6 | 5  | 4 | 3   | 2   | 1   | 0 |
Contenu : | lvl | bs | r | dma | clt | clr | e |

4-3-4. Configurer le modem▲

Bit :     | 7 | 6 | 5  | 4  | 3   | 2   | 1   | 0   |
Contenu : | r | r | af | lb | ao2 | ao1 | rts | dtr |

4-3-5. Écrire des données sur le port série▲

global inb

; inb - retourne un octet reçu du port E/S donné
; pile : [esp + 4] L'adresse du port E/S donné
;        [esp    ] L'adresse de retour
inb:
    mov dx, [esp + 4]    ; déplace l'adresse du port E/S donné dans le registre dx
    in  al, dx           ; lit un octet reçu du port E/S et le stocke dans le registre al
    ret                  ; retourne l'octet lu

/* dans le fichier io.h */

/** inb:
 *  Lit un octet reçu d'un port E/S.
 *
 *  @param  port L'adresse du port E/S
 *  @return      L'octet lu
 */
unsigned char inb(unsigned short port);

#include "io.h"

/** serie_est_transmiss_fifo_vide :
 *  Vérifie si la file FIFO de transmission est vide ou pas pour le   port COM donné.
 *
 *  @param  com  Le port COM
 *  @return      0 si la file FIFO n'est pas vide
 *               1 si la file FIFO de transmission est vide
 */
int serie_is_transmiss_fifo_vide(unsigned int com)
{
    /* 0x20 = 0010 0000 */
    return inb(SERIE_LIGNE_STATUS_PORT(com)) & 0x20;
}

4-3-6. Configurer Bochs▲

    com1: enabled=1, mode=file, dev=com1.out

4-3-7. Le pilote▲

• Le livre « Serial programming » (disponible sur WikiBooks) a une section excellente au sujet de la programmation du port série, http://en.wikibooks.org/wiki/Serial_Programming/8250_UART_Programming#UART_Registers;
• Le wiki OSDev a une page contenant beaucoup d'informations au sujet des ports série, http://wiki.osdev.org/Serial_ports.

La plupart du temps, lors de l'accès en mémoire, il n'est pas besoin de spécifier explicitement le segment à utiliser. Le processeur dispose de six registres de segment de 16 bits : cs, ss, ds, es, gs et fs. Le registre cs (code segment) est le registre de segment du code et spécifie le segment à utiliser lorsqu'on récupère des instructions. Le registre ss (stack segment) est utilisé chaque fois que l'on accède à la pile (à travers le pointeur de pile esp), et ds (data segment) est utilisé pour d'autres accès aux données. L'OS est libre d'utiliser les registres es, gs et fs comme il veut.

Voici un exemple montrant l'utilisation implicite des registres de segment :

func:
    mov eax, [esp+4]
    mov ebx, [eax]
    add ebx, 8
    mov [eax], ebx
    ret

L'exemple ci-dessus peut être comparé à l'exemple suivant, qui montre une utilisation explicite des registres de segments :

func:
    mov eax, [ss:esp+4]
    mov ebx, [ds:eax]
    add ebx, 8
    mov [ds:eax], ebx
    ret

Vous n'avez pas besoin d'utiliser ss pour stocker le sélecteur de segment de la pile, ou ds pour le sélecteur de segment de données. Vous pourriez stocker le sélecteur de segment de la pile dans ds et vice versa. Toutefois, pour pouvoir utiliser le style implicite indiqué ci-dessus, vous devez stocker les sélecteurs de segments dans leurs registres prévus à cette fin.

Les descripteurs de segments et leurs champs sont décrits dans la figure 3-8 dans le manuel Intel(32).

Une GDT/LDT est un « tableau » de descripteurs de segment de 8 octets. Le premier descripteur dans le GDT est toujours un descripteur null et ne peut jamais être utilisé pour accéder à la mémoire. Au moins deux descripteurs de segment (plus le descripteur null) sont nécessaires pour la GDT, parce que le descripteur contient plus d'informations que seulement les champs base et limite. Les plus importants pour nous sont le champ Type et le champ Descripteur de niveau de privilège (Descriptor Privilege Level - DPL).

Le Tableau 3-1 dans le chapitre 3 du manuel Intel (33) spécifie les valeurs pour le champ Type. Il montre que le champ Type ne peut pas être en même temps accessible en écriture et exécutable. Par conséquent, deux segments sont nécessaires : un segment pour l'exécution du code à mettre en cs (Type est en exécution seule ou en exécution et lecture) et un segment pour les données de lecture et d'écriture (Type est en lecture/écriture) à mettre dans les autres registres de segment.

Le DPL précise les niveaux de privilèges nécessaires pour utiliser le segment. Le processeur x86 autorise quatre niveaux de privilèges (PL), de 0 à 3, où PL0 est le plus privilégié. Dans la plupart des systèmes d'exploitation (par ex. Linux et Windows), seulement PL0 et PL3 sont utilisés. Cependant, certains systèmes d'exploitation, tels que MINIX, font usage de tous les niveaux. Le noyau devrait être en mesure de tout faire, donc il utilise des segments avec DPL défini à 0 (également appelé « mode du noyau »). Le niveau de privilège courant (CPL) est déterminé par le sélecteur de segment dans le registre cs.

Les descripteurs de segments nécessaires sont repris ci-dessous.

Notez que les segments se chevauchent - ils englobent tous deux la totalité de l'espace d'adressage linéaire. Dans notre configuration minimale, nous utiliserons uniquement la segmentation pour obtenir des niveaux de privilèges. Voir le manuel Intel (33), chapitre 3, pour plus de détails sur les autres champs de descripteur.

Le chargement de la GDT dans le processeur se fait avec l'instruction en assembleur lgdt, qui a besoin de l'adresse d'une structure spécifiant le début et la taille de la GDT. Il est plus facile à coder ces informations en utilisant une « structure compactéeCompacter les structures », comme dans l'exemple suivant :

struct gdt {
    unsigned int address;
    unsigned short size;
} __attribute__((packed));

Si le registre eax contient l'adresse d'une telle structure, la GDT peut être chargée avec le code assembleur ci-dessous :

lgdt [eax]

Rendre cette instruction disponible à partir de C pourrait faciliter les choses, de la même manière qu'avec les instructions assembleur in et out.

Après le chargement de la GDT, les registres de segment doivent être chargés avec leurs sélecteurs de segment correspondants. Le contenu d'un sélecteur de segment est décrit dans la figure et le tableau ci-dessous :

Bit :     | 15                                3 | 2  | 1 0 |
Contenu : | offset (index)                      | ti | rpl |

Le décalage du sélecteur de segment est ajouté au début de la GDT pour obtenir l'adresse du descripteur de segment : 0x08 pour le premier descripteur et 0x10 pour la deuxième, puisque chaque descripteur est de 8 octets. Le niveau de privilège requis (Requested Privilege Level - RPL) doit être 0 puisque le noyau de l'OS doit s'exécuter dans le niveau de privilège 0.

Le chargement des registres de sélecteur de segment est facile pour les registres de données - il suffit de copier les décalages corrects dans les registres :

mov ds, 0x10
mov ss, 0x10
mov es, 0x10
.
.
.

Pour charger cs, nous devons faire un « saut à distance » :

; ce code utilise le cs précédent
jmp 0x08:flush_cs   ; spécifiez le cs lors du saut à flush_cs

flush_cs:
    ; maintenant, nous avons modifié cs à 0x08

Un saut à distance est un saut où nous spécifions explicitement l'adresse logique complète de 48 bits : le sélecteur de segment à utiliser et l'adresse absolue où sauter. Cela définira d'abord cs à 0x08, puis sautera à flush_cs en utilisant son adresse absolue.

• Le chapitre 3 du manuel Intel (33) est rempli de détails de bas niveau et techniques sur la segmentation.
• Le wiki de OSDev a une page sur la segmentation : http://wiki.osdev.org/Segmentation
• La page Wikipedia sur la segmentation sous x86 pourrait être utile dans la recherche : http://en.wikipedia.org/wiki/X86_memory_segmentation, https://fr.wikipedia.org/wiki/Segmentation_(informatique)

Les interruptions sont traitées via la table de descripteurs d'interruption (Interrupt Descriptor Table - IDT). L'IDT décrit un gestionnaire pour chaque interruption. Les interruptions sont numérotées (0 - 255) et le gestionnaire de l'interruption i est défini à la position i dans la table. Il y a trois types différents de gestionnaires pour interruptions :

• gestionnaire de tâche ;
• gestionnaire d'interruption ;
• gestionnaire d'interception.

Les gestionnaires de tâches utilisent des fonctionnalités spécifiques à la version Intel de x86, ils ne seront pas couverts ici (voir le manuel Intel, chapitre 6, pour plus d'information). La seule différence entre un gestionnaire d'interruption et un gestionnaire d'interception est que le gestionnaire d'interruption désactive les interruptions, ce qui signifie que vous ne pouvez pas avoir une nouvelle interruption lorsque vous en gérez une. Dans ce livre, nous allons utiliser des gestionnaires d'interceptions et désactiver manuellement les interruptions lorsque nous en avons besoin.

Un enregistrement dans l'IDT pour un gestionnaire d'interruption se compose de 64 bits. Les 32 bits supérieurs sont présentés dans la figure ci-dessous :

Bit :     | 31              16 | 15 | 14 13 | 12 | 11 | 10 9 8 | 7 6 5 | 4 3 2 1 0 |
Contenu : | offset supérieur   | P  | DPL   | 0  | D  | 1  1 0 | 0 0 0 |  réservé  |

Les 32 bits inférieurs sont présentés dans la figure ci-dessous :

Bit :     | 31              16 | 15              0 |
Contenu : |sélecteur de segment| offset inférieur  |

Une description pour chaque nom se trouve dans le tableau ci-dessous :

L'offset est un pointeur vers du code (de préférence, une étiquette en code assembleur). Par exemple, pour créer une entrée pour un gestionnaire dont le code commence à 0xDEADBEEF et qui fonctionne en niveau de privilège 0 (donc en utilisant le même sélecteur de segment de code que le noyau), les deux octets suivants seront utilisés :

0xDEAD8E00
0x0008BEEF

Si l'IDT est représentée comme un unsigned integer idt[512], alors pour enregistrer l'exemple ci-dessus en tant que gestionnaire pour interruption 0 (division par zéro), le code suivant serait utilisé :

idt[0] = 0xDEAD8E00
idt[1] = 0x0008BEEF

Comme écrit dans le chapitre « Passage au CPassage au C », nous vous recommandons d'utiliser les structures compactées à la place des octets (ou entiers non signés), pour rendre le code plus lisible.

Lorsqu'une interruption se produit, le CPU va déposer certaines informations à propos de celle-ci sur la pile, puis recherchera le gestionnaire d'interruption approprié dans l'IDT et sautera à celui-ci. La pile au moment de l'interruption va ressembler à ceci :

[esp + 12] eflags
[esp + 8]  cs
[esp + 4]  eip
[esp]      error code?

La raison de la présence du point d'interrogation après error code est que les interruptions ne créent pas toutes un code d'erreur. Les interruptions spécifiques au CPU, qui mettent un code d'erreur sur la pile sont 8, 10, 11, 12, 13, 14 et 17. Le code d'erreur peut être utilisé par le gestionnaire d'interruption pour obtenir plus d'informations sur ce qui est arrivé. En outre, notez que le numéro de l'interruption n'est pas déposé sur la pile. Nous pouvons déterminer quelle interruption a eu lieu uniquement en sachant quel code est exécuté - si le gestionnaire enregistré pour l'interruption 17 est exécuté, alors c'est l'interruption 17 qui a eu lieu.

Une fois que le gestionnaire d'interruption a fini, il utilise l'instruction iret pour retourner. L'instruction iret s'attend à ce que la pile soit la même que juste avant l'interruption (voir la figure ci-dessus). Par conséquent, toutes les valeurs déposées sur la pile par le gestionnaire d'interruption doivent être enlevées. Avant de retourner, iret restaure eflags en éliminant la valeur de la pile, puis finalement saute à cs:eip, comme spécifié par les valeurs sur la pile.

Le gestionnaire d'interruption doit être écrit en code assembleur, puisque tous les registres utilisés par les gestionnaires d'interruption doivent être préservés en les poussant sur la pile. Cela parce que le code qui a été interrompu ignore l'interruption et s'attendra donc à ce que ses registres ne changent pas. L'écriture de toute la logique du gestionnaire d'interruption en code assembleur serait fastidieuse. La création en assembleur d'un gestionnaire qui sauvegarde les registres, appelle une fonction C, restaure les registres et finalement exécute iret est une bonne idée !

Le gestionnaire C devrait obtenir comme arguments l'état des registres, l'état de la pile et le numéro de l'interruption. Les définitions suivantes peuvent par exemple être utilisées :

struct cpu_state {
    unsigned int eax;
    unsigned int ebx;
    unsigned int ecx;
    .
    .
    .
    unsigned int esp;
} __attribute__((packed));

struct stack_state {
    unsigned int error_code;
    unsigned int eip;
    unsigned int cs;
    unsigned int eflags;
} __attribute__((packed));

void interrupt_handler(struct cpu_state cpu, struct stack_state stack, unsigned int interrupt);

Puisque le CPU ne dépose pas sur la pile le numéro de l'interruption, l'écriture d'un gestionnaire d'interruption générique est un peu difficile. Cette section utilisera des macros pour montrer comment faire. L'écriture d'une version pour chaque interruption est fastidieuse, il est préférable d'utiliser la fonctionnalité de macro de NASM(33). Et puisque toutes les interruptions ne produisent pas un code d'erreur, la valeur 0 sera ajoutée comme « code d'erreur » pour les interruptions sans aucun code d'erreur. Le code suivant montre un exemple de la façon dont cela peut être fait :

%macro no_error_code_interrupt_handler %1
global interrupt_handler_%1
interrupt_handler_%1:
    push    dword 0                   ; met 0 comme code d'erreur
    push    dword %1                  ; met le nombre de l'interruption
    jmp     common_interrupt_handler  ; saute au gestionnaire générique
%endmacro

%macro error_code_interrupt_handler %1
global interrupt_handler_%1
interrupt_handler_%1:
    push    dword %1                  ; met le nombre de l'interruption
    jmp     common_interrupt_handler  ; saute au gestionnaire générique
%endmacro

common_interrupt_handler:             ; les parties communes du gestionnaire d'interruption générique
    ; sauvegarder les registres
    push    eax
    push    ebx
    .
    .
    .
    push    ebp

    ; appeler la fonction  C
    call    interrupt_handler

    ; restaurer les registres
    pop     ebp
    .
    .
    .
    pop     ebx
    pop     eax

    ; restaurer le esp
    add     esp, 8

    ; retourner au code qui a été interrompu
    iret

no_error_code_interrupt_handler 0     ; créer gestionnaire pour interruption 0
no_error_code_interrupt_handler 1     ; créer gestionnaire pour interruption 1
.
.
.
error_code_handler              7     ; créer gestionnaire pour interruption 7
.
.
.

Le common_interrupt_handler effectue les opérations suivantes :

• sauvegarde les registres sur la pile ;
• appelle la fonction C interrupt_handler ;
• récupère les registres de la pile ;
• ajoute 8 à esp (à cause du code d'erreur et du numéro de l'interruption déposé plus tôt) ;
• exécute iret pour revenir au code interrompu.

Comme les macros déclarent des étiquettes globales, les adresses des gestionnaires d'interruption peuvent être accessibles à partir du code C ou du code assembleur lors de la création de l'IDT.

L'IDT est chargée avec l'instruction en assembleur lidt, qui prend l'adresse du premier élément dans le tableau. Le plus simple est d'incorporer cette instruction dans du code C :

global  load_idt

; load_idt - Charge la table de descripteurs d'interruptions (IDT).
; pile : [esp + 4] l'adresse du premier enregistrement dans l'IDT
;        [esp    ] l'adresse de retour
load_idt:
    mov     eax, [esp+4]    ; charge l'adresse de l'IDT dans le registre eax
    lidt    eax             ; charge l'IDT
    ret                     ; retourne à la fonction appelante

Pour commencer à utiliser les interruptions matérielles, vous devez d'abord configurer le contrôleur d'interruption programmable (Programmable Interrupt Controller - PIC). Le PIC rend possible le mappage des signaux provenant du matériel vers des interruptions. Les raisons pour configurer le PIC sont :

• modifier le mappage des interruptions. Le PIC utilise par défaut les interruptions 0-15 pour les interruptions matérielles, ce qui entre en conflit avec les interruptions du CPU. Par conséquent, les interruptions PIC doivent être réaffectées à un autre intervalle ;
• sélectionner les interruptions à recevoir. Vous ne voulez probablement pas recevoir des interruptions de tous les périphériques, puisque de toute façon vous ne disposez pas de code qui gère ces interruptions ;
• configurer le mode correct pour le PIC.

Au début, il n'y avait qu'un seul PIC (PIC 1) et huit interruptions. Comme on a ajouté plus de matériel, 8 interruptions ne suffisaient pas. La solution retenue a été d'enchaîner un autre PIC (PIC 2) au premier PIC (voir l'interruption 2 sur PIC 1).

Les interruptions matérielles sont présentées dans le tableau ci-dessous :

Un excellent tutoriel pour configurer le PIC peut être trouvé sur le site web de SigOPS(34). Nous ne répéterons pas cette information ici.

La réception de chaque interruption envoyée par le PIC doit être confirmée, c'est-à-dire qu'il faut envoyer au PIC un message confirmant que l'interruption a été gérée. Si cela n'est pas fait, le PIC ne générera aucune autre interruption.

La confirmation de réception d'une interruption se fait par l'envoi de l'octet 0x20 au PIC qui a déclenché l'interruption. Mettre en œuvre une fonction de pic_acknowledge peut donc se faire comme suit :

#include "io.h"

#define PIC1_PORT_A 0x20
#define PIC2_PORT_A 0xA0

/* Le mappage des interruptions PIC a été modifié */
#define PIC1_START_INTERRUPT 0x20
#define PIC2_START_INTERRUPT 0x28
#define PIC2_END_INTERRUPT   PIC2_START_INTERRUPT + 7

#define PIC_ACK     0x20

/** pic_acknowledge:
 *  Confirme la réception d'une interruption à partir de PIC 1 ou PIC 2.
 *
 *  @param num Le numéro de l'interruption
 */
void pic_acknowledge(unsigned integer interruption)
{
    if (interruption < PIC1_START_INTERRUPT || interruption > PIC2_END_INTERRUPT) {
        return;
    }

    if (interruption < PIC2_START_INTERRUPT) {
        outb(PIC1_PORT_A, PIC_ACK);
    } else {
        outb(PIC2_PORT_A, PIC_ACK);
    }
}

Le clavier ne génère pas de caractères ASCII, il génère des codes de balayage. Un code de balayage représente un bouton - les deux actions, appuyer et relâcher. Le code de balayage représentant le bouton juste enfoncé peut être lu à partir du port de données d'E/S du clavier, dont l'adresse 0x60. La façon de le faire est présentée dans l'exemple suivant :

#include "io.h"

#define KBD_DATA_PORT   0x60

/** read_scan_code :
 *  Lit un code de balayage à partir du clavier
 *
 *  @return Le code de balayage (PAS un caractère ASCII !)
 */
unsigned char read_scan_code(void)
{
    return inb(KBD_DATA_PORT);
}

L'étape suivante est d'écrire une fonction qui traduit un code de balayage en caractère ASCII correspondant. Si vous souhaitez mapper les codes de balayage vers des caractères ASCII comme on le fait sur un clavier américain, alors Andries Brouwer a écrit un excellent tutoriel(35) à ce sujet.

Comme l'interruption clavier est levée par le PIC, n'oubliez pas que vous devez appeler pic_acknowledge à la fin du gestionnaire d'interruption du clavier. En outre, le clavier ne vous enverra aucune autre interruption jusqu'à ce que vous lisiez le code de balayage du clavier.

• Le wiki de OSDev contient une page excellente sur les interruptions, http://wiki.osdev.org/Interrupts
• Le chapitre 6 du manuel Intel 3a (33) décrit tout ce qu'il y a à savoir sur les interruptions.

D'où pouvons-nous obtenir le programme externe ? D'une façon ou d'une autre, nous avons besoin de charger dans la mémoire le code que nous voulons exécuter. Les systèmes d'exploitation plus évolués ont généralement des pilotes et des systèmes de fichiers qui leur permettent de charger le logiciel à partir d'un lecteur de CD-ROM, un disque dur ou d'autres médias persistants.

Au lieu de créer tous ces pilotes et systèmes de fichiers, nous allons utiliser la fonctionnalité modules de GRUB pour charger le programme.

7-1-1. Les modules GRUB▲

module /modules/program

mkdir -p iso/modules

; dans le fichier `loader.s`


NOMBRE_MAGIQUE  equ 0x1BADB002      ; définir la constante nombre magique
ALIGN_MODULES   equ 0x00000001      ; dire à GRUB d'aligner les modules

; calculer la somme de contrôle CHECKSUM (toutes les options + somme de contrôle doit être égal à 0)
CHECKSUM        equ -(NOMBRE_MAGIQUE + ALIGN_MODULES)

section .text:                      ; début de la section de texte (code) 
align 4                             ; le code doit être aligné sur 4 octets
    dd NOMBRE_MAGIQUE               ; écrit le nombre magique
    dd ALIGN_MODULES                ; écrit l'instruction d'alignement des modules
    dd CHECKSUM                     ; écrit la somme de contrôle

7-2-1. Un programme très simple▲

; affecter à eax un nombre facile à distinguer, à lire ensuite dans le journal
mov eax, 0xDEADBEEF

; entrer dans la boucle infinie, rien de plus à faire
; $ signifie "début de ligne", c.-à-d la même instruction
jmp $

7-2-2. Compiler▲

nasm -f bin program.s -o program

7-2-3. Trouver le programme en mémoire▲

int kmain(/* arguments additionnels */ unsigned int ebx)
{
    multiboot_info_t *mbinfo = (multiboot_info_t *) ebx;
    unsigned int adresse_du_module = mbinfo->mods_addr;
}

7-2-4. Sauter au code▲

typedef void (*call_module_t)(void);
/* ... */
call_module_t start_program = (call_module_t) adresse_du_module;
start_program();
/* nous n'arrivons jamais ici, sauf si le code du module retourne */

Le programme que nous avons écrit s'exécute maintenant au même niveau de privilège que le noyau - nous y sommes juste entrés d'une manière un peu particulière. Pour permettre aux applications de s'exécuter à un niveau de privilège différent, nous devrons, en plus de la segmentationSegmentation, nous occuper de la paginationPagination et de l'allocation de trame de pageAllocation de trames de page.

Cela représente pas mal de travail et de détails techniques à traverser, mais d'ici quelques chapitres vous aurez des programmes fonctionnant en mode utilisateur.

Vous pourriez vous passer complètement de la pagination et utiliser juste la segmentation pour la mémoire virtuelle. Chaque processus en mode utilisateur obtiendrait son propre segment, avec l'adresse de base et la limite correctement mises en place. De cette façon, aucun processus ne peut voir la mémoire d'un autre processus. Dans ce cas-là, un problème est que la mémoire physique pour un processus doit être contiguë (ou du moins, c'est très pratique si elle l'est). Soit nous devons savoir à l'avance combien de mémoire utilisera le programme (c'est peu probable), soit nous pouvons déplacer les segments de mémoire, lorsque la limite est atteinte, dans des endroits où ils peuvent croître (ce qui est coûteux, entraîne une fragmentation et peut déboucher sur une erreur « mémoire insuffisante » même s'il y a assez de mémoire est disponible). La pagination résout ces problèmes.

Il est intéressant de noter que dans x86_64 (la version 64 bits de l'architecture x86), la segmentation est presque complètement éliminée.

• Sur LWN.net il y a un article sur la mémoire virtuelle : http://lwn.net/Articles/253361/
• Gustavo Duarte a écrit également un article sur la mémoire virtuelle : http://duartes.org/gustavo/blog/post/memory-translation-and-segmentation

La pagination est la technique la plus couramment utilisée dans l'architecture x86 pour permettre la mémoire virtuelle. La mémoire virtuelle par le biais de la pagination signifie que chaque processus aura l'impression que la plage de mémoire disponible est 0x00000000 - 0xFFFFFFFF, même si la taille réelle de la mémoire est peut-être bien moindre. Cela signifie également que lorsqu'un processus accède à un octet de mémoire, il utilisera une adresse virtuelle (linéaire) au lieu d'une adresse physique. Le code dans le processus de l'utilisateur ne remarquera aucune différence (sauf pour les délais d'exécution). L'adresse linéaire est traduite en une adresse physique par la MMU et la table des pages. Si l'adresse virtuelle n'est pas mappée à une adresse physique, le processeur déclenchera une interruption de défaut de page.

La pagination est facultative et certains systèmes d'exploitation n'en font pas usage. Mais si nous voulons marquer certaines zones de mémoire comme accessibles seulement à l'exécution du code ayant un certain niveau de privilège (pour être en mesure d'avoir des processus s'exécutant à différents niveaux de privilège), la pagination est la façon la plus élégante de le faire.

La pagination en x86 (le chapitre 4 du manuel Intel) se compose d'une table répertoire de page (page directory, ou PDT) qui peut contenir des références vers 1024 tables des pages (PT), dont chacune peut pointer vers 1024 sections de mémoire physique appelées trames de page (PF). Chaque trame de page a une taille de 4096 octets. Dans une adresse virtuelle (linéaire), les 10 bits de poids fort spécifient le décalage d'une entrée de répertoire de page (page directory entry - PDE) dans le PDT courant, les 10 bits suivants - le décalage d'une entrée de table des pages (page table entry - PTE) dans la table des pages pointée par ce PDE. Les 12 bits de poids faible de l'adresse représentent le décalage dans le cadre de page à traiter.

Tous les répertoires de pages, tables de pages et trames de pages doivent être alignés sur des adresses de 4096 octets. Cela permet d'adresser une PDT, PT ou PF avec seulement les 20 bits les plus forts d'une adresse de 32 bits, puisque les 12 bits inférieurs doivent être nuls.

La structure des PDE et celle des PTE sont très semblables, chacune ayant 32 bits (4 octets), où les 20 bits les plus hauts pointent vers une PTE ou PF, et les 12 bits les plus faibles contrôlent les droits d'accès et autres configurations. 4 octets fois 1024 est égal à 4096 octets, donc un répertoire de page et une table de pages rentrent tous les deux dans une trame de page.

La traduction des adresses linéaires en adresses physiques est décrite dans la figure ci-dessous.

Bien que les pages aient normalement 4096 octets, il est également possible d'utiliser des pages de 4 Mo. Une PDE pointe ensuite directement vers une trame de page de 4 Mo, qui doit être alignée sur une limite d'adresse de 4 Mo. La traduction d'adresse est presque la même que sur la figure, avec juste l'étape de table de page supprimée. Il est possible de mélanger des pages de 4 Mo et de 4 ko.

Les 20 bits pointant vers la PDT courante sont stockés dans le registre cr3. Les 12 bits inférieurs de cr3 sont utilisés pour la configuration.

Pour plus de détails sur les structures des pages, voir le chapitre 4 dans le manuel Intel (33). Les bits les plus intéressants sont U/S, qui déterminent quels niveaux de privilèges peuvent accéder à cette page (PL0 ou PL3), et R/W, ce qui rend la mémoire dans la page disponible en lecture-écriture ou en lecture seule.

9-2-1. Pagination d'identité▲

9-2-2. Activer la pagination▲

; eax contient l'adresse du répertoire de la page
mov cr3, eax

mov ebx, cr4        ; lire la valeur courante de cr4
or  ebx, 0x00000010 ; définir PSE
mov cr4, ebx        ; mettre à jour cr4

mov ebx, cr0        ; lire la valeur courante de cr0
or  ebx, 0x80000000 ; définir PG
mov cr0, ebx        ; mettre à jour cr0

; la pagination est maintenant activée

9-2-3. Quelques détails▲

; rend invalide toute référence dans le TLB vers l'adresse virtuelle 0
invlpg [0]

Cette section décrira comment la pagination affecte le noyau de l'OS. Nous vous encourageons à gérer votre OS en utilisant la pagination d'identité avant d'essayer de mettre en œuvre une configuration de pagination plus avancée, car il peut être difficile de déboguer une table de page dysfonctionnelle mise en place en code assembleur.

9-3-1. Raisons de ne pas utiliser le mappage d'identité pour le noyau▲

9-3-2. L'adresse virtuelle pour le noyau▲

9-3-3. Placer le noyau à 0xC0000000▲

9-3-4. Script d'éditeur de liens de la moitié supérieure▲

ENTRY(loader)        /* le nom du symbole en entrée */

. = 0xC0100000       /* le code devrait être be relocalisé à 3Go + 1Mo */

/* alignement à 4 ko et chargement à 1 Mo */
.text ALIGN (0x1000) : AT(ADDR(.text)-0xC0000000)
{
    *(.text)         /* toutes les sections texte, de tous les fichiers */
}

/* alignement à 4 ko et chargement à 1 Mo + . */
.rodata ALIGN (0x1000) : AT(ADDR(.text)-0xC0000000)
{
    *(.rodata*)      /* toutes les sections de données en lecture seule, de tous les fichiers */
}

/* alignement à 4 ko et chargement à 1 Mo + . */
.data ALIGN (0x1000) : AT(ADDR(.text)-0xC0000000)
{
    *(.data)         /* toutes les sections de données, de tous les fichiers */
}

/* alignement à 4 ko et chargement à 1 MB + . */
.bss ALIGN (0x1000) : AT(ADDR(.text)-0xC0000000)
{
    *(COMMON)        /* toutes les sections COMMON, de tous les fichiers */
    *(.bss)          /* toutes les sections bss, de tous les fichiers */
}

9-3-5. Accéder à la moitié supérieure▲

; code assembleur s'exécutant alentour de 0x00100000
; active la pagination tant pour l'emplacement réel du noyau
; que pour son adresse virtuelle dans la moitié supérieure

lea ebx, [higher_half] ; charge l'adresse de l'étiquette dans ebx
jmp ebx                ; saute à l'étiquette

higher_half:
    ; le code ici s'exécute dans le noyau de la moitié supérieure
    ; eip est plus large que 0xC0000000
    ; peut continuer l'initialisation du noyau, appels au code C, etc.

9-3-6. Exécuter dans la moitié supérieure▲

La pagination permet deux choses qui sont bonnes pour la mémoire virtuelle. Tout d'abord, elle permet un contrôle à granulation fine de l'accès à la mémoire. Vous pouvez marquer les pages en lecture seule, lecture et écriture, seulement pour PL0, etc. Deuxièmement, il crée l'illusion d'une mémoire contiguë. Les processus en mode utilisateur et le noyau peuvent accéder à la mémoire comme si elle était contiguë et la mémoire contiguë peut être étendue sans avoir besoin de déplacer des données en mémoire. Nous pouvons également permettre aux programmes en mode utilisateur d'accéder à toute la mémoire en dessous de 3 Go, mais à moins qu'ils l'utilisent réellement, nous ne devons pas assigner des trames de page aux pages. Cela permet aux processus d'avoir le code situé près de 0x00000000 et la pile à juste en dessous de 0xC0000000 et de n'avoir toujours pas besoin de plus de deux pages réelles.

• Le chapitre 4 (et dans une certaine mesure le chapitre 3) du manuel Intel (33) sont vos sources définitives pour les détails sur la pagination.
• Wikipédia fournit un article sur la pagination : http://en.wikipedia.org/wiki/Paging, https://fr.wikipedia.org/wiki/Mémoire_virtuelle#M.C3.A9moire_virtuelle_pagin.C3.A9e.
• Le wiki de OSDev contient une page au sujet de la pagination : http://wiki.osdev.org/Paging et un tutoriel pour faire un noyau de moitié supérieure : http://wiki.osdev.org/Higher_Half_bare_bones.
• L'article de Gustavo Duarte sur la façon dont un noyau gère la mémoire mérite bien une lecture : http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory.
• Des détails sur le langage de commande de l'éditeur des liens peuvent être trouvés sur le site de Steve Chamberlain (37).
• Plus de détails sur le format ELF peuvent être trouvés dans cette présentation : http://flint.cs.yale.edu/cs422/doc/ELF_Format.pdf.

10-1-1. Combien de mémoire se trouve là ?▲

ENTRY(loader)        /* le nom du symbole en entrée */

. = 0xC0100000       /* le code doit être relocalisé à 3 Go + 1 Mo */

/* ces étiquettes seront exportées dans les fichiers de code */
kernel_virtual_start = .;
kernel_physical_start = . - 0xC0000000;

/* alignement à 4 ko et chargement à 1 Mo */
.text ALIGN (0x1000) : AT(ADDR(.text)-0xC0000000)
{
    *(.text)         /* toutes les sections texte, de tous les fichiers */
}

/* alignement à 4 ko et chargement à 1 Mo + . */
.rodata ALIGN (0x1000) : AT(ADDR(.rodata)-0xC0000000)
{
    *(.rodata*)      /* toutes les sections de données en lecture seule, de tous les fichiers */
}

/* alignement à 4 ko et chargement à 1 Mo + . */
.data ALIGN (0x1000) : AT(ADDR(.data)-0xC0000000)
{
    *(.data)         /* toutes les sections de données, de tous les fichiers */
}

/* alignement à 4 ko et chargement à 1 MB + . */
.bss ALIGN (0x1000) : AT(ADDR(.bss)-0xC0000000)
{
    *(COMMON)        /* toutes les sections COMMON, de tous les fichiers */
    *(.bss)          /* toutes les sections bss, de tous les fichiers */
}

kernel_virtual_end = .;
kernel_physical_end = . - 0xC0000000;

extern kernel_virtual_start
extern kernel_virtual_end
extern kernel_physical_start
extern kernel_physical_end

; ...

push kernel_physical_end
push kernel_physical_start
push kernel_virtual_end
push kernel_virtual_start

call kmain

void kernel_virtual_start(void);

/* ... */

unsigned int vaddr = (unsigned int) &kernel_virtual_start;

10-1-2. Gérer la mémoire disponible▲

Nous devons mapper la trame de page dans la mémoire virtuelle en mettant à jour la PDT et/ou la PT utilisée par le noyau. Que se passe-t-il si toutes les tables de pages disponibles sont pleines ? Dans ce cas-là, nous ne pouvons pas mapper la trame de page en mémoire, parce que nous aurions besoin d'une nouvelle table de page - qui occupe toute une trame de page - et pour écrire dans cette trame de page, nous devrions mapper sa trame de page... Il faut rompre d'une façon ou d'une autre ce cercle vicieux.

Une solution consiste à réserver une partie de la première table de page utilisée par le noyau (ou une autre table de page de la moitié supérieure) pour mapper temporairement les trames de page afin de les rendre accessibles. Si le noyau est mappé à 0xC0000000 (enregistrement du répertoire de page avec l'indice 768), et 4 ko de trames de page sont utilisés, alors le noyau a au moins une table de page. Si nous supposons - ou nous limitons à - un noyau de taille d'au plus 4 Mo moins 4 ko, nous pouvons consacrer le dernier enregistrement (enregistrement 1023) de cette table de page pour mappages temporaires. L'adresse virtuelle des pages mappées en utilisant le dernier enregistrement de la PT du noyau sera :

(768 << 22) | (1023 << 12) | 0x000 = 0xC03FF000

Après avoir mappé temporairement la trame de page que nous voulons utiliser comme table de page et l'avoir configurée pour mapper vers notre première trame de page, nous pouvons l'ajouter au répertoire de pagination et supprimer le mappage temporaire.

Jusqu'à présent, nous avons été en mesure de travailler seulement avec des données de taille fixe, ou directement avec de la mémoire brute. Maintenant que nous avons un allocateur de trame de page, nous pouvons mettre en œuvre des fonctions malloc et free pour les utiliser dans le noyau.

Kernighan et Ritchie donnent dans leur livre (8)un exemple d'implémentation dont nous pouvons nous inspirer. La seule modification que nous devons faire est de remplacer les appels à sbrk/brk par des appels à l'allocateur de trame de page lorsque plus de mémoire est nécessaire. Nous devons également veiller à mapper vers des adresses virtuelles les trames de page renvoyées par l'allocateur. Une mise en œuvre correcte doit également retourner des trames de page à l'allocateur lors d'appels à la fonction free, chaque fois que des blocs de mémoire suffisamment de grands sont libérés.

• La page OSDev wiki sur l'allocation de trame de page : http://wiki.osdev.org/Page_Frame_Allocation.

Pour activer le mode utilisateur, nous devons ajouter deux segments supplémentaires à la GDT. Ceux-ci sont très semblables aux segments du noyau que nous avons ajoutés lorsque nous avons configuré la GDTLa table de descripteurs globaux (GDT), dans le chapitre sur la segmentationSegmentation :

Les descripteurs de segment nécessaires pour le mode utilisateur

La différence est le DPL, qui permet maintenant l'exécution du code en niveau de privilège PL3. Les segments peuvent toujours être utilisés pour accéder à tout l'espace d'adresses, ce qui veut dire que l'utilisation de ces segments pour le code en mode utilisateur ne protégera pas le noyau. Pour cela, nous avons besoin de pagination.

Il y a quelques petites choses dont chaque processus en mode utilisateur a besoin :

• des trames de page pour le code, les données et la pile. Pour le moment, il suffit d'allouer une trame de page pour la pile et suffisamment de trames de page pour contenir le code du programme. Pour l'instant, ne vous préoccupez pas de la mise en place d'une pile qui peut grandir et rétrécir, concentrez-vous d'abord sur l'obtention d'une mise en Å“uvre simple ;
• le binaire du module GRUB doit être copié dans les trames de page utilisées pour le code des programmes ;
• un répertoire de pages et des tables de pages sont nécessaires pour mapper en mémoire les trames de page décrites ci-dessus. Au moins deux tables de pages sont nécessaires, parce que le code et les données doivent être mappés au 0x00000000 et augmenter, et la pile doit commencer juste en dessous du noyau, à 0xBFFFFFFB et croître vers des adresses inférieures. Le drapeau U/S doit être configuré pour permettre l'accès PL3.

Il pourrait être pratique de stocker ces informations dans une struct représentant un processus. Cette struct de processus peut être allouée dynamiquement avec la fonction malloc du noyau.

La seule façon d'exécuter du code avec un niveau de privilège inférieur au niveau de privilège courant (current privilege level - CPL) est d'exécuter une instruction iret ou lret - retour ou long retour après interruption, respectivement.

Pour entrer en mode utilisateur, nous mettons en place la pile comme si le processeur avait lancé une interruption de niveau inter-privilège. La pile doit ressembler à ce qui suit :

[esp + 16]  ss      ; le sélecteur de segment de pile que nous voulons pour le mode utilisateur
[esp + 12]  esp     ; le pointeur de pile en mode utilisateur
[esp +  8]  eflags  ; les options de contrôle que nous voulons utiliser en mode utilisateur
[esp +  4]  cs      ; le sélecteur de segment de code
[esp +  0]  eip     ; le pointeur d'instruction du code du mode utilisateur à exécuter

Voir le manuel Intel (33), section 6.2.1, figure 6-4 pour plus d'informations.

L'instruction iret lira alors ces valeurs de la pile et remplira les registres correspondants. Avant d'exécuter iret, nous devons changer de répertoire vers celui configuré pour le processus en mode utilisateur. Il est important de rappeler que pour poursuivre l'exécution de code du noyau après avoir changé de PDT, le noyau doit être mappé. Une façon d'accomplir cela est d'avoir une PDT séparée pour le noyau, qui mappe toutes les données à 0xC0000000 et au-dessus, et la fusionner avec la PDT de l'utilisateur (qui ne mappe qu'en dessous de 0xC0000000) lors de l'exécution du changement de répertoire. Rappelez-vous que l'adresse physique de la PDT doit être utilisée lors de la configuration du registre cr3.

Le registre eflags contient un ensemble d'indicateurs différents, spécifiés dans la section 2.3 du manuel Intel (33). Le plus important pour nous est celui d'activation d'interruption (interrupt enable flag - IF). L'instruction assembleur sti ne peut pas être utilisée pour activer les interruptions au niveau de privilège 3. Si les interruptions sont désactivées en entrant en mode utilisateur, elles ne peuvent plus être activées une fois en mode utilisateur. Le placement de l'indicateur IF sur la pile, dans l'entrée eflags, activera les interruptions en mode utilisateur, puisque l'instruction en assembleur iret configurera le registre eflags à la valeur correspondante sur la pile.

Pour l'instant, nous devrions avoir désactivé les interruptions, car il faut un peu plus de travail pour faire fonctionner correctement les interruptions de niveau interprivilège (voir la section Appels systèmeAppels système).

La valeur eip sur la pile doit pointer vers le point d'entrée du code utilisateur - 0x00000000 dans notre cas. La valeur esp sur la pile doit être là où la pile commence - 0xBFFFFFFB (0xC0000000 - 4).

Les valeurs cs et ss sur la pile doivent être les sélecteurs de segment pour les segments de code et respectivement de données de l'utilisateur. Comme nous l'avons vu dans le chapitre sur la segmentationSegmentation, les deux bits inférieurs d'un sélecteur de segment définissent le RPL - le niveau de privilège requis. Lors de l'utilisation de iret pour entrer en PL3, le RPL de cs et ss doit être 0x3. Le code suivant montre un exemple :

USER_MODE_CODE_SEGMENT_SELECTOR equ 0x18
USER_MODE_DATA_SEGMENT_SELECTOR equ 0x20
mov cs, USER_MODE_CODE_SEGMENT_SELECTOR | 0x3
mov ss, USER_MODE_DATA_SEGMENT_SELECTOR | 0x3

Le registre ds et les autres registres de segments de données doivent être configurés sur le même sélecteur de segment que ss. Ils peuvent être définis de la façon habituelle, avec l'instruction assembleur mov.

Nous sommes maintenant prêts à exécuter iret. Si tout a été mis en place correctement, nous devrions maintenant avoir un noyau qui peut entrer en mode utilisateur.

Lorsque le C est utilisé comme langage de programmation pour les programmes en mode utilisateur, il est important de réfléchir à la structure du fichier qui résultera de la compilation.

La raison pour laquelle nous pouvons utiliser ELF (18) comme format de fichier pour l'exécutable du noyau est parce que GRUB sait comment analyser et interpréter le format de fichier ELF. Si nous avions mis en œuvre un analyseur de ELF, nous pourrions aussi compiler les programmes en mode utilisateur en binaires ELF. Nous laissons cela comme un exercice pour le lecteur.

Pour faciliter le développement des programmes en mode utilisateur, nous pouvons permettre aux programmes d'être écrits en C, mais les compiler en binaires plats au lieu de binaires ELF. En C, la mise en page du code généré est plus imprévisible et le point d'entrée, main, pourrait ne pas être à l'offset 0 dans le binaire. Une façon courante de contourner cela est d'ajouter quelques lignes de code assembleur placées à l'offset 0, qui appellent main :

extern main

section .text
    ; push argv
    ; push argc
    call main
    ; main a retourné, eax est la valeur de retour
    jmp  $    ; boucle infinie

Si ce code est enregistré dans un fichier appelé start.s, alors le code suivant montre un exemple de script d'édition de liens qui place ces instructions d'abord en exécutable (rappelez-vous que start.s est compilé en start.o) :

OUTPUT_FORMAT("binary") /* output binaire plat */

SECTIONS
{
    . = 0;              /* relocaliser à l'adresse 0 */

    .text ALIGN(4):
    {
        start.o(.text)  /* inclure la section .text de start.o */
        *(.text)        /* inclure les autres sections .text */
    }

    .data ALIGN(4):
    {
        *(.data)
    }

    .rodata ALIGN(4):
    {
        *(.rodata*)
    }
}

Avec ce script, nous pouvons écrire des programmes en C ou assembleur (ou tout autre langage qui compile en fichiers objet pouvant être liés avec ld), et le noyau les chargera et mappera facilement (cependant , .rodata sera mappé comme étant en écriture).

Lorsque nous compilons des programmes utilisateur, nous voulons les options GCC suivantes :

    -m32 -nostdlib -nostdinc -fno-builtin -fno-stack-protector
    -nostartfiles  -nodefaultlibs

Pour l'édition des liens, les options suivantes doivent être utilisées :

    -T link.ld -melf_i386  # émuler ELF 32 bits, la sortie binaire est spécifiée
                           # dans le script d'édition de liens

L'option -T indique à l'éditeur de liens d'utiliser le script d'édition de liens link.ld.

11-4-1. Une bibliothèque C▲

• Gustavo Duarte a un article sur les niveaux de privilèges : http://duartes.org/gustavo/blog/post/cpu-rings-privilege-and-protection.

Comment pouvons-nous préciser quels programmes exécuter dans notre OS ? Quel est le premier programme à exécuter ? Comment les programmes font-ils pour produire des données ou en lire en entrée ?

Dans les systèmes de type UNIX, qui ont pour convention que presque tout est un fichier, ces problèmes sont résolus par le système de fichiers. (Il pourrait également être intéressant à lire un peu sur le projet Plan 9 de Bell Labs, qui pousse l'idée du « tout fichier » un cran plus loin.)

Le système de fichiers le plus simple pourrait être ce que nous avons déjà - un seul fichier, existant uniquement dans la RAM, chargé par GRUB avant le démarrage du noyau. Lorsque le noyau et le système d'exploitation croissent, cela devient probablement trop limitatif.

Un fichier avec des métadonnées est un système de fichiers légèrement plus avancé que celui représenté seulement par les bits d'un seul fichier. Les métadonnées peuvent décrire le type du fichier, sa taille et ainsi de suite. Un programme utilitaire qui s'exécute à la compilation peut être créé en ajoutant ces métadonnées dans un fichier. De cette façon, un « système de fichiers dans un fichier » peut être construit par la concaténation de plusieurs fichiers avec des métadonnées dans un grand fichier. Le résultat de cette technique est un système de fichiers en lecture seule qui réside dans la mémoire (une fois que GRUB a chargé le fichier).

Le programme qui construit le système de fichiers peut traverser un répertoire sur le système hôte et ajouter tous les sous-répertoires et les fichiers dans le cadre du système de fichiers cible. Chaque objet dans le système de fichiers (répertoire ou fichier) peut consister en un en-tête et un corps, où le corps d'un fichier est le fichier même et le corps d'un répertoire est une liste d'entrées - noms et « adresses » d'autres fichiers et répertoires.

Les objets dans ce système de fichiers deviendront contigus, donc le noyau les lira facilement dans la mémoire. Tous les objets auront également une taille fixe (à l'exception du dernier, qui peut augmenter), il est donc difficile d'ajouter de nouveaux fichiers ou de modifier ceux qui existent.

Lorsque l'on envisage un système de fichiers accessible en écriture, c'est une bonne idée de se pencher sur le concept d'un nœud d'index ou inode. Voir la section Lectures complémentairesLectures complémentaires pour des lectures recommandées.

Quelle abstraction utiliser pour la lecture et l'écriture sur les dispositifs tels que l'écran et le clavier ?

Un système virtuel de fichiers (VFS) crée une abstraction au-dessus des systèmes de fichiers concrets. Un VFS fournit principalement le système de chemins et une hiérarchie de fichiers, il délègue les opérations sur les fichiers aux systèmes de fichiers sous-jacents. Le document original sur les VFS est succinct et mérite bien une lecture. Voir la section Lectures complémentairesLectures complémentaires pour une référence.

Avec un VFS, nous pourrions monter un système de fichiers spécial sur le chemin /dev. Ce système de fichiers gérerait tous les périphériques tels que les claviers et la console. Cependant, on pourrait aussi suivre l'approche traditionnelle UNIX, avec numéros majeurs/mineurs de périphériques et mknod pour créer des fichiers spéciaux pour ces périphériques. C'est à vous de choisir l'approche que vous pensez être la plus adaptée, il n'y a pas de chose juste ni de chose incorrecte lors de la construction des couches d'abstraction (bien que certaines abstractions se révèlent beaucoup plus utiles que d'autres).

• Les idées derrière les systèmes d'exploitation Plan 9 valent la peine d'y jeter un coup d'Å“il : http://plan9.bell-labs.com/plan9/index.html
• La page de Wikipédia sur les nÅ“uds d'index : https://fr.wikipedia.org/wiki/NÅ“ud_d'index et la structure de pointeur de nÅ“ud d'index : http://en.wikipedia.org/wiki/Inode_pointer_structure
• Le document original sur le concept de vnodes et de système de fichiers virtuel est assez intéressant : https://cgi.cse.unsw.edu.au/~cs3231/15s1/assignments/asst2/kleiman86vnodes.pdf (NdT)
• Poul-Henning Kamp discute de l'idée d'un système de fichiers spécial pour /dev dans http://static.usenix.org/publications/library/proceedings/bsdcon02/full_papers/kamp/kamp_html/index.html

C'est à nous, les développeurs du noyau, de concevoir les appels système que les développeurs d'applications peuvent utiliser. Nous pouvons nous inspirer des normes POSIX ou, si elles semblent trop de travail, il suffit de regarder ceux pour Linux et de choisir. Voir la section Lecture complémentaireLecture complémentaire à la fin du chapitre 10 pour références.

Les appels système sont traditionnellement invoqués avec des interruptions logicielles. Les applications de l'utilisateur mettent les valeurs appropriées dans les registres ou sur la pile puis déclenchent une interruption prédéfinie, qui transfère l'exécution au noyau. Le numéro d'interruption utilisé dépend du noyau, Linux utilise le numéro 0x80 pour identifier une interruption destinée à déclencher un appel système.

Lors de l'exécution des appels système, le niveau de privilège actuel passe généralement de PL3 à PL0 (si l'application s'exécute en mode utilisateur). Il faut donc que le DPL de l'enregistrement de l'IDT correspondant à l'interruption d'appel système permette l'accès PL3.

Chaque fois que des interruptions impliquant un changement de niveau de privilège se produisent, le processeur dépose quelques registres importants sur la pile - les mêmes que nous avons utilisés précédemment pour entrer en mode utilisateur ; voir la figure 6-4, section 6.12.1, dans le manuel Intel (33). Quelle pile utiliser ? La même section dans le manuel Intel précise que si une interruption conduit à l'exécution de code ayant un niveau de privilège numériquement plus faible, un changement de pile se produit. Les nouvelles valeurs pour les registres ss et esp sont chargées à partir du segment d'état de tâche (TSS) courant. La structure du TSS est spécifiée dans la figure 7-2, la section 7.2.1 du manuel Intel.

Pour activer les appels système, nous devons mettre en place un TSS avant d'entrer en mode utilisateur. Sa mise en place peut être faite en C, en définissant les champs ss0 et esp0 d'une « struct compactée » qui représente un TSS. Avant de charger la « struct compactée » dans le processeur, un descripteur TSS doit être ajouté à la GDT. La structure du descripteur TSS est décrite dans la section 7.2.2 du manuel Intel.

Vous spécifiez le sélecteur de segment TSS courant en le chargeant dans le registre tr avec l'instruction assembleur ltr. Si le descripteur de segment TSS a l'index 5, et ainsi le décalage est 5 * 8 = 40 = 0x28, celle-ci est la valeur qui doit être chargée dans le registre tr.

Lorsque nous sommes entrés en mode utilisateur dans le chapitre Entrer en mode utilisateurEntrer en mode utilisateur, nous avons désactivé les interruptions lors de l'exécution en PL3. Puisque les appels système sont mis en œuvre en utilisant les interruptions, les interruptions doivent être activées en mode utilisateur. En définissant le bit indicateur IF à la valeur eflags sur la pile, nous ferons en sorte que iret active les interruptions (puisque la valeur eflags sur la pile sera chargée dans le registre eflags par l'instruction assembleur iret).

• La page Wikipédia sur POSIX, avec des liens vers les spécifications : https://fr.wikipedia.org/wiki/POSIX
• Une liste des appels système utilisés dans Linux : http://bluemaster.iu.hio.no/edu/dark/lin-asm/syscalls.html
• La page Wikipédia sur l'appel système : https://fr.wikipedia.org/wiki/Appel_système
• Les sections du manuel Intel (33) sur les interruptions (chapitre 6) et TSS (chapitre 7) sont la source de référence où vous obtiendrez tous les détails dont vous avez besoin.

La création de nouveaux processus est généralement faite par deux appels système différents : fork et exec. fork crée une copie exacte du processus en cours d'exécution, tandis qu'exec remplace le processus courant avec celui spécifié par un chemin d'accès à l'emplacement d'un programme dans le système de fichiers. Entre ces deux options, nous vous recommandons de commencer par la mise en œuvre d'exec, puisque cet appel système va suivre presque exactement les mêmes étapes que celles décrites dans la section Configurer le mode utilisateurConfigurer le mode utilisateur du chapitre Mode utilisateurMode utilisateur.

La façon la plus facile d'effectuer une commutation rapide entre processus est de rendre les processus eux-mêmes responsables de la commutation. Les processus sont exécutés pendant un certain temps, puis disent au système d'exploitation (via un appel système) qu'il peut maintenant passer à un autre processus. Rendre le contrôle du CPU à l'autre processus s'appelle rendre la main et lorsque les processus eux-mêmes sont responsables de l'ordonnancement, on appelle cela le mode coopératif, puisque tous les processus doivent coopérer les uns avec les autres.

Quand un processus rend la main, tout l'état du processus doit être enregistré (tous les registres), de préférence sur le tas du noyau, dans une structure qui représente un processus. Lors du passage à un nouveau processus, tous les registres doivent être restaurés à partir des valeurs enregistrées.

L'ordonnancement peut être mis en œuvre en gardant une liste des processus qui sont en cours d'exécution. L'appel système yield doit ensuite donner la main au processus suivant de la liste et mettre celui qui rend la main en dernier (d'autres mécanismes sont possibles, mais celui-ci est le plus simple).

Le transfert du contrôle au nouveau processus se fait via l'instruction assembleur iret, exactement de la même manière que cela a été fait dans la section Entrer en mode utilisateurEntrer en mode utilisateur du chapitre Mode utilisateurMode utilisateur.

Nous recommandons fortement que vous commenciez par mettre en œuvre un mode multitâche coopératif. Nous recommandons en outre que vous ayez mis au point une solution fonctionnelle à la fois pour exec, fork et yield avant de vous lancer dans le mode multitâche préemptif. Comme le mode coopératif est déterministe, il est beaucoup plus facile à déboguer que le mode préemptif.

Au lieu de laisser les processus décider eux-mêmes quand rendre la main à un autre processus, l'OS peut commuter automatiquement les processus après une courte période de temps. Le système d'exploitation peut régler la minuterie d'intervalle programmable (PIT) pour lancer une interruption après une courte période de temps, par exemple 20 millisecondes. Dans le gestionnaire d'interruptions pour l'interruption PIT, l'OS va remplacer le processus en cours par un autre. De cette façon, les processus eux-mêmes ne doivent pas se préoccuper de l'ordonnancement. Ce type d'ordonnancement est appelé mode préemptif.

14-3-1. Minuterie d'intervalle programmable (Programmable Interval Timer - PIT)▲

14-3-2. Piles séparées dans le noyau pour les processus▲

14-3-3. Difficultés de l'ordonnancement préemptif▲

• Pour plus d'informations sur les différents algorithmes d'ordonnancement, voir http://wiki.osdev.org/Scheduling_Algorithms