Processus et appels système

Un navigateur, un compilateur et un lecteur de musique peuvent tous progresser sur un même ordinateur. Chacun a besoin de temps processeur, de mémoire et d’un accès aux périphériques. Le système d’exploitation fournit ces ressources par des services que les programmes peuvent utiliser sans contrôler toute la machine.

Fournir des ressources utiles aux programmes

La virtualisation transforme une ressource physique en une ressource virtuelle pratique. La virtualisation du processeur permet à de nombreux processus de se comporter comme si chacun avait son propre processeur. Le système d’exploitation exécute chacun pendant un certain temps et conserve son état entre ses tours. La virtualisation de la mémoire donne à chaque processus son propre espace d’adressage : les adresses que ses instructions peuvent utiliser.

Une abstraction masque des détails derrière une interface utile. Un fichier est une abstraction pour des octets stockés. Un programme peut appeler write sans savoir si ces octets vont vers un SSD ou un lecteur réseau. Un appel système fournit un moyen contrôlé de demander un service au noyau. Le travail propre au périphérique reste masqué derrière l’interface.

Partager les ressources et protéger les programmes

En tant que gestionnaire de ressources, le système d’exploitation décide qui obtient du temps processeur, de la mémoire et des services des périphériques. Il cherche à utiliser efficacement le matériel tout en donnant aux programmes un accès raisonnable. Le partage exige aussi une protection : un programme ne doit pas écraser la mémoire privée d’un autre ni désactiver l’horloge pour garder le processeur.

Le matériel aide à faire respecter cette frontière. Les instructions des applications s’exécutent en mode utilisateur avec des droits limités. Le code noyau s’exécute avec les privilèges nécessaires pour gérer la machine. Une horloge peut interrompre un programme même si celui-ci ne demande jamais rien au système d’exploitation.

Pour un ordinateur portable qui télécharge un fichier tout en compilant du code, suis trois tâches distinctes :

1. Le périphérique réseau signale l’arrivée de données. Le noyau les met à la disposition du processus de téléchargement.
2. Le système d’exploitation partage le temps processeur entre le navigateur, le compilateur et les autres processus prêts.
3. Le compilateur demande des opérations sur des fichiers pour stocker sa sortie. Son code ne pilote pas directement le contrôleur de stockage.

Séparer le noyau de l’interface

Le noyau est le cœur privilégié. L’interpréteur de commandes, l’environnement graphique et la plupart des bibliothèques système s’exécutent comme des programmes ordinaires, même lorsqu’ils sont distribués avec le système d’exploitation. Fermer une fenêtre du bureau ne supprime pas le noyau. Un serveur sans interface graphique a toujours besoin de gestion des processus, de protection mémoire et de services pour les périphériques.

Sur un processeur logique, le code utilisateur et le code noyau s’exécutent à tour de rôle. Pendant que le compilateur exécute des instructions utilisateur ordinaires, le noyau ne s’exécute pas en même temps sur ce processeur. Les appels système, les exceptions et les interruptions matérielles lui rendent le contrôle.

Choisir comment faire, puis à qui attribuer

Un mécanisme fournit une opération ; une politique choisit comment l’utiliser. Sauvegarder les registres d’un processus et restaurer ceux d’un autre est un mécanisme. Choisir quel processus prêt obtient le prochain tour relève d’une politique. Cette séparation permet au système d’exploitation de changer ses choix d’ordonnancement sans remplacer le mécanisme de commutation.

La conception d’un système d’exploitation concilie des abstractions utiles, les performances, la protection, la fiabilité, la sécurité et la consommation d’énergie. Le temps processeur et la mémoire supplémentaires consacrés à la gestion constituent un surcoût. Dans tout le domaine, trois thèmes reviennent : la virtualisation, la concurrence (des activités en cours pendant une même période) et la persistance, qui conserve les données stockées au-delà de la durée de vie d’un programme ou d’une coupure de courant.

Les systèmes d’exploitation ont évolué lorsque les ordinateurs sont passés de l’exécution de tâches isolées à la prise en charge de nombreuses activités à la fois. Chaque changement a résolu un problème pratique : matériel inactif, interaction lente ou propagation des défaillances entre programmes.

Des lots au recouvrement des tâches

Dans le traitement par lots, les tâches soumises s’exécutent les unes après les autres sans interaction avec la personne qui les a soumises. Les premiers logiciels d’assistance aidaient surtout à charger les tâches et à effectuer les opérations courantes d’entrée-sortie. Si la tâche en cours devait attendre un périphérique, le processeur pouvait rester inactif.

La multiprogrammation maintient plusieurs tâches en mémoire. Lorsque l’une se bloque en attendant une entrée-sortie, une autre peut effectuer des calculs. Supposons qu’une tâche calcule de façon répétée pendant 20 ms puis attende une entrée-sortie disque pendant 80 ms. Seule, son taux d’utilisation du processeur est de 20 / 100 = 20 %. Avec deux tâches de ce type et un recouvrement adapté, les calculs utiles peuvent occuper 40 % du temps écoulé. L’attente du périphérique n’a pas raccourci ; les calculs occupent du temps processeur qui aurait autrement été perdu.

Le gain dépend de la présence de tâches prêtes. Ajouter des tâches ne peut pas porter le taux d’utilisation du processeur au-delà de 100 %, et les tâches qui attendent le même périphérique peuvent toujours se heurter à un goulet d’étranglement. Plusieurs tâches en mémoire nécessitent aussi une protection : l’une ne doit pas écraser une autre ni endommager les données propres au système d’exploitation.

Rendre l’interaction réactive

Le partage du temps donne aux processus de courts tours sur le processeur. Un terminal ou un environnement graphique peut répondre pendant que d’autres programmes continuent leur travail. Attendre la fin d’une tâche par lots avant de traiter la frappe d’un autre utilisateur donnerait une impression très différente.

La concurrence signifie que plusieurs activités sont en cours pendant une même période. Leurs instructions peuvent être entrelacées sur un processeur logique. Le parallélisme signifie que des instructions s’exécutent réellement en même temps sur différentes ressources de traitement. La multiprogrammation ne nécessite pas de matériel parallèle.

Placer les services dans le noyau ou à l’extérieur

Linux est monolithique et peut charger des modules noyau. MINIX 3, QNX et seL4 illustrent les architectures à micronoyau. Windows NT et XNU d’Apple sont généralement décrits comme des architectures hybrides. Un pilote en mode utilisateur peut souvent être redémarré après une panne, tandis qu’un pilote privilégié dispose d’un accès tel que sa défaillance peut toucher tout le système.

Les premiers systèmes pour ordinateurs personnels, comme MS-DOS et le Mac OS classique, ne disposaient pas de la protection de la mémoire des processus attendue aujourd’hui. Les systèmes modernes combinent les règles du système d’exploitation et leur application par le matériel. De courts tours sur le processeur ne suffiraient pas à empêcher un programme de modifier la mémoire d’un autre ; le partage et la protection résolvent des aspects différents du problème.

Un exécutable sur disque peut être lancé plusieurs fois. Chaque lancement a besoin de son propre état évolutif pour qu’une instance puisse être suspendue, reprendre ou échouer indépendamment des autres. Cette instance active est un processus.

Identifier l’instance en cours d’exécution

Un programme est constitué d’instructions et de données statiques stockées. Un processus combine un programme avec sa mémoire courante, ses registres du processeur et son état d’entrée-sortie. Trois interpréteurs de commandes peuvent exécuter le même fichier tout en gardant des variables, des répertoires courants et des historiques différents.

Le compteur ordinal (PC) indique la prochaine instruction. Le pointeur de pile indique l’emplacement de la pile active. Les registres généraux contiennent des valeurs intermédiaires. Lorsqu’un processus cesse de s’exécuter, une partie suffisante de son état doit être conservée pour qu’il puisse continuer à la bonne instruction avec les bonnes valeurs.

Lire le schéma de l’espace d’adressage

L’espace d’adressage d’un processus est la mémoire que ses instructions peuvent adresser. Dans une organisation pédagogique courante, le code et les données statiques se trouvent vers les adresses basses, le tas au-dessus et la pile vers les adresses hautes. Le tas accueille les objets alloués dynamiquement ; la pile prend en charge les appels de fonctions et l’état local. Dans cette organisation, le tas grandit vers les adresses hautes et la pile vers les adresses basses. Les organisations réelles dépendent du système et les implémentations de malloc peuvent obtenir de la mémoire de plusieurs façons.

Deux processus peuvent afficher la même adresse virtuelle pour une variable tout en y conservant des valeurs différentes. Les adresses virtuelles appartiennent à la vue qu’un processus a de la mémoire. Des numéros d’adresse identiques ne prouvent pas que le stockage accessible en écriture est partagé.

Démarrer un programme

Pour démarrer une nouvelle image de programme, le système d’exploitation met en place les éléments suivants :

1. Son code exécutable et ses données, dont certaines parties sont chargées au besoin sur les systèmes modernes.
2. Une pile utilisateur initiale et des informations de démarrage, notamment les chaînes d’arguments et le vecteur d’arguments utilisés par l’environnement d’exécution pour appeler main.
3. De la mémoire pour l’allocation dynamique et l’état initial des registres.
4. Un environnement d’entrée-sortie, notamment les descripteurs de fichier hérités.
5. Un point d’entrée où commence le code de démarrage du programme.

Sous Unix, les descripteurs de fichier sont de petits entiers qui désignent des ressources d’entrée-sortie ouvertes. Par convention dans l’interpréteur de commandes, 0 est l’entrée standard, 1 la sortie standard et 2 l’erreur standard. Ils sont souvent reliés à un terminal. Un processus peut hériter de descripteurs supplémentaires ; les trois numéros habituels ne constituent ni une limite ni une garantie qu’ils sont toujours ouverts dans chaque processus.

Examiner l’enregistrement du noyau

Le bloc de contrôle de processus (PCB) enregistre les informations dont le noyau a besoin pour gérer un processus : PID, état, contexte d’exécution sauvegardé, informations mémoire, descripteurs ouverts, père, propriétaire, répertoire courant et données de comptabilisation. Linux utilise task_struct ; xv6 utilise struct proc. Une table ou une liste des processus organise ces enregistrements.

Pendant qu’un processus s’exécute, ses registres courants sont dans le processeur. À l’entrée dans le noyau, ses registres utilisateur sont sauvegardés sur sa pile noyau ; une commutation de contexte conserve aussi le contexte d’exécution du noyau. Le PCB n’est pas un miroir constamment à jour de chaque registre utilisateur.

Par exemple, une sortie de ps sous Linux peut contenir 8240 8200 S bash et 8291 8240 R ps. Le second processus a le PID 8291 et le PID de son père est 8240 : il est donc le fils de l’interpréteur de commandes. R couvre les processus en cours d’exécution et les processus prêts. Un PID identifie un processus actif dans son espace de noms PID, mais après le nettoyage, ce numéro peut être réutilisé.

Un processus peut exister sans exécuter d’instruction à un instant donné. Son état indique au système d’exploitation s’il peut utiliser un processeur ou s’il doit d’abord attendre autre chose. Cette distinction explique pourquoi un ordinateur occupé peut avoir de nombreux processus, mais seulement quelques-uns en cours d’exécution à un instant donné.

Déterminer ce dont le processus a besoin

Un processus bloqué ne consomme aucun temps processeur tant qu’il est bloqué. Son périphérique ou l’événement attendu peut néanmoins progresser. Un processus prêt possède déjà tout ce dont il a besoin, sauf un processeur.

Les transitions de base sont prêt → en cours d’exécution lorsqu’il est sélectionné, en cours d’exécution → prêt lorsqu’il est retiré du processeur, en cours d’exécution → bloqué lorsqu’il doit attendre, et bloqué → prêt lorsque l’événement attendu se produit. La fin de l’événement rend un processus admissible à l’exécution ; elle ne lui donne pas immédiatement le processeur. Choisir parmi les processus admissibles est le rôle de l’ordonnanceur.

Suivre le recouvrement des tâches

Utilise un processeur logique et néglige le surcoût des commutations de contexte. Le processus A calcule pendant 2 ms, attend une entrée-sortie disque pendant 3 ms, puis calcule pendant 1 ms. Le processus B a besoin de 4 ms de temps processeur. A commence en premier.

À 2 ms, A lance l’entrée-sortie et se bloque. B calcule pendant que le disque travaille. À 5 ms, l’entrée-sortie de A se termine, mais le système d’exploitation laisse B terminer sa quatrième milliseconde de temps processeur avant d’exécuter A. C’est un choix de politique, pas une transition supplémentaire directement de l’état bloqué à l’état en cours d’exécution.

Le travail total du processeur est de 2 + 1 + 4 = 7 ms, et les deux processus terminent après 7 ms. Si A s’exécutait jusqu’à sa fin avant que B commence, le temps écoulé serait de 2 + 3 + 1 + 4 = 10 ms. Le taux d’utilisation du processeur serait de 7 / 10 = 70 %, car aucun autre travail n’occuperait le temps d’attente de l’entrée-sortie.

Lire les états sur un système réel

Sous Linux, ps regroupe les états en cours d’exécution et prêt sous R. Il affiche le sommeil interruptible sous S, le sommeil non interruptible, souvent lié aux entrées-sorties, sous D, un processus arrêté sous T et un processus terminé mais non récupéré sous Z. Un processus arrêté n’attend pas simplement la fin d’une entrée-sortie ordinaire. Un zombie a terminé son exécution et ne conserve que l’enregistrement nécessaire pour communiquer son résultat.

Un nouveau processus passe aussi par une phase de création avant d’être prêt. Sur un système doté de quatre processeurs logiques, au plus quatre processus à un seul fil d’exécution peuvent s’exécuter simultanément. Les files des processus prêts organisent les tâches admissibles ; les listes des processus bloqués suivent les événements qu’ils attendent. Une commutation de contexte conserve l’état d’exécution d’un processus et restaure celui d’un autre lorsque le système d’exploitation change le processus en cours d’exécution.

fork() crée un processus fils à partir du père appelant. Les deux poursuivent leur exécution immédiatement après l’appel : un chemin du code source donne donc lieu à deux exécutions. La valeur de retour indique à chaque processus quel est son rôle.

Traiter les trois résultats

pid_t rc = fork();
if (rc < 0) {
    perror("fork");
    exit(1);
} else if (rc == 0) {
    printf("child %ld\n", (long) getpid());
} else {
    printf("parent of %ld\n", (long) rc);
}

Utilise <unistd.h> pour fork et getpid, <stdio.h> pour l’affichage et <stdlib.h> pour exit. En cas de succès, le père reçoit le PID positif du fils ; le fils reçoit 0. En cas d’échec, l’appelant reçoit -1, errno indique l’erreur et aucun fils n’est créé.

Si le père a le PID 5000 et le fils le PID 5001, le père affiche « parent of 5001 » et le fils affiche « child 5001 ». Rien ne garantit lequel des deux s’exécute en premier. getpid() renvoie le PID de l’appelant ; getppid() renvoie le PID de son père. Le fils ne redémarre pas main et ne répète pas les instructions précédant le fork.

Suivre la mémoire privée et les entrées-sorties partagées

Le père et le fils commencent avec des contenus de mémoire ordinaire identiques dans des espaces d’adressage distincts. Si x vaut 10 avant l’appel et que le fils donne la valeur 20 à sa copie, celle du père reste à 10. Même l’adresse affichée de x peut être identique : ces adresses virtuelles égales appartiennent aux espaces d’adressage de processus différents.

La copie sur écriture évite de copier immédiatement chaque page mémoire. Le père et le fils partagent initialement les pages physiques, protégées en écriture. Lorsque l’un écrit dans une page privée, le noyau crée une copie privée avant d’autoriser l’écriture. Cela conserve le comportement de mémoires distinctes tout en réduisant le coût lorsqu’un fils appelle rapidement exec.

Les descripteurs de fichier se comportent différemment. Leurs entrées copiées renvoient à la même description de fichier ouvert sous-jacente, qui comprend le déplacement courant dans le fichier. Les lectures séquentielles effectuées au moyen d’un descripteur hérité font avancer ce déplacement partagé. La table des descripteurs est copiée, mais l’état sous-jacent du fichier ouvert dans le noyau peut rester partagé.

Ne compter que les forks atteints par un processus

Si tous les appels réussissent, fork(); fork(); laisse quatre processus : les deux processus issus du premier appel exécutent le second. Une boucle de trois itérations atteinte par tous les processus laisse $2^3=8$ processus, dont l’original. Un fork situé dans une branche réservée au père est atteint par moins de processus : des doublements répétés ne décrivent alors plus l’ensemble du programme.

Vider volontairement le texte mis en tampon

printf peut laisser du texte dans un tampon de l’espace utilisateur. fork copie ce tampon avec le reste de la mémoire. Si la sortie est redirigée vers un flux entièrement mis en tampon, le texte affiché avant le fork peut être vidé par les deux processus lors de leur terminaison normale.

Avec printf("start\n"); fork();, le terminal habituel, dont la sortie est mise en tampon par ligne, vide la ligne avant le fork grâce au saut de ligne. Un fichier vers lequel la sortie est redirigée peut la conserver et en recevoir deux copies. fflush(stdout) avant fork() envoie une seule fois le texte en attente. Le doublon provient des données mises en tampon qui ont été copiées, et non d’une double exécution du printf précédent.

Un processus peut garder son identité tout en changeant le programme qu’il exécute. La famille exec effectue ce remplacement. La combiner avec fork permet à un père de continuer son travail pendant qu’un fils devient un autre programme.

Remplacer l’image, conserver le processus

Un exec réussi remplace l’ancien code, les données statiques, le tas et la pile. Le noyau prépare les arguments et l’état initial du nouveau programme, puis démarre son code de démarrage. Le point où l’ancien appel a été effectué n’existe plus : un exec réussi n’y revient donc jamais.

Le PID, le lien avec le père et le répertoire courant sont conservés. Les descripteurs ouverts le sont aussi, sauf ceux marqués pour la fermeture à l’exécution. Les signaux interceptés retrouvent leur comportement par défaut ; ceux qui sont ignorés restent généralement ignorés. Les identifiants restent habituellement les mêmes, mais les permissions set-user-ID ou set-group-ID d’un exécutable peuvent modifier les identifiants effectifs lorsque le système l’autorise.

Construire un vecteur d’arguments valide

Pour exécuter wc -l notes.txt, le fils peut utiliser :

char *args[] = {"wc", "-l", "notes.txt", NULL};
execvp(args[0], args);
perror("execvp");
_exit(127);

Les chaînes sont des arguments distincts, pas une seule ligne de commande combinée. Par convention, args[0] désigne le programme. Le NULL final est un pointeur qui marque la fin du tableau ; ce n’est pas la chaîne « NULL ». Sans marqueur de fin valide, l’appel peut lire au-delà du tableau.

Les lignes qui suivent execvp traitent l’échec. Si le programme est introuvable, exec renvoie -1 et définit errno, par exemple à ENOENT. _exit termine alors le fils sans vider les tampons de sortie C hérités. Revenir dans la boucle de l’interpréteur après un échec créerait accidentellement un second chemin d’exécution de l’interpréteur.

Lire le nom de la variante

Le v de execv signifie que les arguments arrivent sous forme de vecteur ; les variantes l reçoivent une liste. Une variante p cherche un nom de programme dans PATH. Une variante e fournit un environnement explicite. L’appel système sous-jacent de Linux est execve ; la bibliothèque fournit les variantes pratiques.

execvp("wc", args) cherche dans PATH. execv("wc", args) traite « wc » comme un chemin relatif dans le répertoire courant. Un chemin absolu comme /usr/bin/wc peut être utilisé là où cet exécutable est installé. Exec n’analyse pas la syntaxe de l’interpréteur de commandes : une chaîne > dans args est un simple argument, sauf si un programme l’interprète lui-même.

Utiliser le temps avant le remplacement

Dans l’exemple où le père a le PID 6000 et le fils le PID 6001, le fils devient wc mais conserve le PID 6001. Son père peut attendre ce PID. Avant exec, le fils peut rediriger des descripteurs, connecter un tube ou changer de répertoire ; le programme de remplacement hérite de l’environnement ainsi préparé.

Cette séparation est essentielle à l’interpréteur de commandes Unix. Sous Windows, CreateProcess combine la création et le chargement du programme, avec des paramètres qui configurent le nouveau processus. POSIX propose aussi posix_spawn pour combiner ces opérations.

Un père doit savoir si un fils a terminé et comment il s’est terminé. La terminaison du processus et la récupération du résultat sont deux étapes distinctes : le fils se termine, puis son père récupère l’enregistrement restant dans le noyau.

Terminer un processus

Revenir de main ou appeler exit(status) met fin à l’exécution normale. exit vide les tampons de sortie C et exécute les fonctions de fin enregistrées. _exit(status) termine le processus sans ce nettoyage de bibliothèque, ce qui est utile après un exec échoué dans un fils créé par fork. Par convention, 0 indique une réussite et une valeur non nulle un échec.

Un signal peut aussi terminer un processus. SIGTERM demande sa terminaison et peut être traité ; SIGKILL ne peut être ni intercepté ni ignoré. SIGSTOP arrête l’exécution et ne peut pas non plus être intercepté ou ignoré ; SIGCONT reprend un processus arrêté. Un terminal envoie normalement SIGINT pour Ctrl-C et SIGTSTP pour Ctrl-Z à la tâche au premier plan. Un signal est une notification logicielle adressée à un processus, et non une interruption matérielle.

Attendre un résultat

wait(&status) attend un fils et renvoie son PID. waitpid(pid, &status, 0) sélectionne un PID positif correspondant à un fils particulier. Un fils terminé et non récupéré peut être récupéré immédiatement. Sinon, une attente bloquante ordinaire suspend le père jusqu’à ce qu’un résultat correspondant soit disponible.

Avec WNOHANG, waitpid renvoie 0 lorsque des fils correspondants existent mais qu’aucun résultat n’est prêt. Un résultat positif identifie le fils récupéré. Un résultat de -1 indique une erreur : ECHILD signifie qu’il ne reste aucun fils correspondant ; EINTR signifie qu’un gestionnaire de signal a interrompu l’attente.

Décoder l’état avant de l’utiliser

int status;
pid_t r;
do {
    r = waitpid(child, &status, 0);
} while (r == -1 && errno == EINTR);
if (r == -1) {
    perror("waitpid");
} else if (WIFEXITED(status)) {
    printf("exit %d\n", WEXITSTATUS(status));
} else if (WIFSIGNALED(status)) {
    printf("signal %d\n", WTERMSIG(status));
}

Ce code utilise <sys/wait.h>, <errno.h> et <stdio.h>. L’état stocké encode la manière dont le processus s’est terminé ainsi qu’un résultat. WEXITSTATUS a un sens après un résultat vrai de WIFEXITED ; WTERMSIG s’utilise après WIFSIGNALED.

Seuls les huit bits de poids faible d’une valeur de sortie normale sont disponibles. exit(300) donne donc 44, tandis que exit(-1) donne 255. Sous Linux, exit(3) produit généralement l’état retourné par wait brut 768 ; afficher cet entier brut ne revient pas à décoder le code de sortie.

Récupérer les zombies et reconnaître les orphelins

Un processus zombie s’est terminé mais conserve son PID et son résultat jusqu’à ce qu’une attente les récupère. Il n’exécute aucun code : lui envoyer SIGKILL ne peut donc pas le supprimer. Un père qui s’exécute longtemps doit récupérer chacun de ses fils. Pour tous les récupérer, continue d’attendre après chaque PID positif, réessaie en cas de EINTR et arrête-toi sur ECHILD ; signale les autres erreurs.

Un processus orphelin a perdu son père et peut encore s’exécuter. Linux lui attribue comme nouveau père un processus récupérateur approprié ou le processus init de l’espace de noms, qui pourra récupérer son résultat plus tard. Les permissions ordinaires d’envoi de signaux dépendent des identités utilisateur et des privilèges. S’exécuter en tant que root accorde des permissions, mais pas une exécution en mode noyau.

Un interpréteur de commandes transforme le texte des commandes en création de processus, configuration de descripteurs et récupération de résultats. C’est un programme utilisateur ordinaire qui utilise les mêmes services protégés du système d’exploitation que les autres programmes.

Lancer une commande externe

Pour wc -l notes.txt, l’interpréteur construit le vecteur d’arguments et lance la commande. Les mots analysés forment un vecteur d’arguments args terminé par un pointeur nul :

pid_t child = fork();
if (child == -1) {
    perror("fork");
} else if (child == 0) {
    execvp(args[0], args);
    perror("execvp");
    _exit(127);
} else {
    int status;
    pid_t result;
    do {
        result = waitpid(child, &status, 0);
    } while (result == -1 && errno == EINTR);
    if (result == -1) perror("waitpid");
    else if (WIFEXITED(status)) {
        printf("exit %d\n", WEXITSTATUS(status));
    } else if (WIFSIGNALED(status)) {
        printf("signal %d\n", WTERMSIG(status));
    }
}

Ce code utilise <unistd.h>, <sys/wait.h>, <errno.h> et <stdio.h>. L’interpréteur qui l’entoure lit et analyse chaque commande, exécute cette procédure de lancement, puis affiche l’invite suivante.

Seul le fils remplace son programme ; l’interpréteur peut récupérer le plantage d’une commande comme résultat de terminaison. Les commandes internes comme cd doivent modifier l’état propre de l’interpréteur : changer le répertoire d’un fils laisserait celui de l’interpréteur père inchangé.

Rediriger un descripteur avant exec

Pour ls -l > out.txt, le fils ouvre la destination en écriture, en la créant ou en la tronquant. Il fait ensuite en sorte que la sortie standard désigne ce fichier :

int fd = open("out.txt", O_WRONLY | O_CREAT | O_TRUNC, 0644);
if (fd == -1) { perror("open"); _exit(1); }
if (dup2(fd, STDOUT_FILENO) == -1) {
    perror("dup2"); _exit(1);
}
if (fd != STDOUT_FILENO && close(fd) == -1) {
    perror("close"); _exit(1);
}

open nécessite <fcntl.h> ; les appels sur les descripteurs et _exit utilisent <unistd.h>. Le mode de création est filtré par le masque de création de fichiers du processus. La vérification fd != STDOUT_FILENO garde le descripteur 1 ouvert même si open lui-même a renvoyé 1. Après une configuration réussie, exec conserve le descripteur 1 et ls écrit normalement sans connaître la redirection.

Une approche plus ancienne ferme le descripteur 1 avant d’ouvrir le fichier : open renvoie le plus petit descripteur inutilisé. dup2 indique explicitement la destination. La redirection de l’entrée relie de la même façon un fichier lisible au descripteur 0.

Relier deux commandes

Pour ls | wc -l, pipe(fds) crée une extrémité de lecture fds[0] et une extrémité d’écriture fds[1]. Le fils producteur relie l’extrémité d’écriture au descripteur 1. Le fils consommateur relie l’extrémité de lecture au descripteur 0. Après la duplication, chacun ferme les descripteurs d’origine du tube dont il n’a pas besoin. Le père ferme ses copies et attend les deux fils.

Crée les deux fils avant d’attendre l’un d’eux. Un producteur peut remplir le tube et se bloquer ; le lecteur doit exister pour le vider. Le lecteur n’atteint la fin de fichier que lorsque tous les descripteurs d’écriture sont fermés et que les données du tube mises en tampon ont été consommées. Une extrémité d’écriture inutilisée que le père garde ouverte peut faire attendre wc indéfiniment.

Garder l’invite disponible

Pour sleep 60 &, l’interpréteur lance le fils et présente l’invite suivante sans attendre immédiatement. Il utilise ensuite des attentes non bloquantes ou réagit à SIGCHLD pour récupérer les fils terminés.

Le code de sortie contrôle aussi les combinaisons de commandes. make && ./app ne lance la seconde commande qu’en cas de réussite ; make || echo failed ne lance la seconde qu’en cas d’échec. Ces décisions utilisent le résultat décodé, et non l’état retourné par wait brut et encodé.

Le noyau doit laisser les programmes calculer rapidement tout en bloquant les opérations qui pourraient prendre le contrôle de la machine. Le mode de privilège du processeur est la frontière matérielle qui rend les deux possibles.

Séparer les calculs du contrôle privilégié

En mode utilisateur, les instructions peuvent accéder à la mémoire autorisée du processus et effectuer des calculs ordinaires. Elles ne peuvent pas modifier librement la configuration matérielle qui protège les autres programmes. En mode noyau, aussi appelé mode superviseur ou privilégié, le système d’exploitation peut effectuer les opérations protégées nécessaires à la gestion de la machine.

Les opérations privilégiées comprennent la programmation de l’horloge, la désactivation des interruptions, l’installation de gestionnaires d’interruption, la modification des registres de contrôle de la traduction des adresses mémoire, le contrôle direct de périphériques protégés et l’arrêt du processeur. Si n’importe quelle application pouvait désactiver l’horloge, les courts tours sur le processeur dépendraient de sa coopération.

AArch64 fournit aussi EL2 pour les hyperviseurs et EL3 pour le micrologiciel sécurisé. Ces noms désignent des niveaux de privilège matériels, et non différents types de comptes utilisateur.

Entrer à une adresse contrôlée

Le code utilisateur ne peut pas augmenter ses propres privilèges ni choisir une adresse quelconque du noyau à exécuter. L’entrée se fait par un appel système, une exception provoquée par une instruction ou une interruption matérielle. Le processeur transfère le contrôle à un point d’entrée configuré par le système d’exploitation. Le code de retour du noyau restaure l’état utilisateur sauvegardé et abaisse le niveau de privilège pour reprendre le code de l’application.

Le noyau protège aussi ses données par des permissions mémoire. Un processus peut avoir des adresses du noyau dans son espace virtuel sans pour autant avoir la permission d’y accéder en mode utilisateur. Connaître une adresse ne donne pas accès aux octets qui s’y trouvent.

Considère une application Linux sur x86-64 qui exécute hlt, une instruction destinée à arrêter un processeur jusqu’à un événement. En mode utilisateur, l’instruction provoque une exception. Linux envoie normalement SIGSEGV, dont l’action par défaut termine ce processus. L’application n’arrête pas tout l’ordinateur ; la frontière de protection transforme la tentative d’opération privilégiée en un événement traité par le noyau.

Distinguer l’identité du mode

Un processus root ou administrateur reste un programme en mode utilisateur pendant l’exécution de ses propres instructions. Son identité utilisateur lui donne des permissions plus larges pour demander des services. Il entre toujours dans le noyau par des voies contrôlées et le noyau vérifie la requête.

Par exemple, un utilitaire de maintenance privilégié peut être autorisé à ouvrir un fichier protégé. L’utilitaire le demande par un appel système ; il ne devient pas du code noyau simplement parce que la requête est autorisée. À l’inverse, lorsque le code noyau traite un read d’un utilisateur ordinaire, il s’exécute en mode noyau même si l’appelant n’a pas d’identité administrative.

Sur un processeur logique, il s’agit d’une séquence : instructions utilisateur, entrée dans le noyau, travail du noyau, retour aux instructions utilisateur. Il ne s’agit pas de l’exécution simultanée d’un programme et d’une seconde tâche du système d’exploitation sur ce même processeur. Des processeurs logiques distincts peuvent exécuter du code dans différents modes au même instant.

Un programme C semble souvent appeler une fonction ordinaire lorsqu’il a besoin d’un service du système d’exploitation. Sous la fonction d’enveloppe d’un appel système, une transition contrôlée du processeur permet au code noyau de vérifier et d’exécuter cette requête.

Distinguer un appel de bibliothèque d’une requête au noyau

La bibliothèque C implémente strlen dans l’espace utilisateur sans appel système. printf met les données en forme et peut les placer en tampon ; un write ultérieur transfère les octets par l’intermédiaire du noyau. Une fine fonction d’enveloppe read prépare les arguments selon la convention d’appel système de la plateforme et exécute l’instruction d’entrée.

POSIX décrit des interfaces pour les systèmes de type Unix. Linux implémente de nombreux services regroupés de façon générale en contrôle des processus, opérations sur les fichiers et les périphériques, information, communication et protection. Un numéro d’appel système sélectionne un service dans la table de répartition du noyau. Les numéros dépendent de la plateforme : Linux sur x86-64 utilise 1 pour write et 39 pour getpid ; sur AArch64, il utilise 64 pour write.

Suivre une requête d’écriture

Pour write(1, "hi\n", 3) sous Linux sur x86-64, suis la requête dans l’ordre :

1. La fonction d’enveloppe place le numéro de service 1 dans rax, le descripteur 1 dans rdi, l’adresse du tampon dans rsi et le nombre 3 dans rdx.
2. syscall conserve l’adresse de retour et les indicateurs dans des registres, passe en mode noyau et saute au point d’entrée configuré. L’instruction ne change pas automatiquement de pile.
3. Le code d’entrée du noyau met en place la pile noyau du processus et sauvegarde le reste de l’état utilisateur.
4. La répartition dans le noyau sélectionne write ; son implémentation vérifie le descripteur, l’accès au tampon utilisateur et la requête avant de transmettre les octets vers la ressource de sortie.
5. Si l’écriture réussit complètement, le résultat est de 3 octets. Le code de retour du noyau restaure l’état utilisateur et reprend la fonction d’enveloppe, qui revient à l’appelant.

Le descripteur 1 peut désigner un terminal, un fichier ou un tube. Le numéro seul n’identifie pas le périphérique de sortie. Une écriture réussie peut aussi renvoyer un nombre d’octets inférieur ; les appelants qui doivent transférer chaque octet suivent la quantité effectivement écrite.

Vérifier les erreurs à l’interface

Le noyau considère que les pointeurs utilisateur et les autres arguments ne sont pas fiables. Une demande de copie depuis un tampon inaccessible peut échouer avec EFAULT ; la copie contrôlée évite d’accorder à l’appelant un accès à la mémoire du noyau.

Sous Linux, une erreur du noyau est un code d’erreur négatif. La fonction d’enveloppe C habituelle renvoie -1 et définit errno. Par exemple, si open("missing.txt", O_RDONLY) échoue parce que le fichier n’existe pas, errno vaut ENOENT. perror("missing.txt") peut afficher « missing.txt: No such file or directory ». Examine errno après un échec signalé, et non comme test principal de réussite : un appel réussi n’est pas tenu d’effacer une erreur précédente.

Tenir compte du temps passé dans le noyau

Un appel qui peut se terminer immédiatement peut revenir au même processus. Une lecture bloquante sur le terminal peut au contraire faire passer ce processus à l’état bloqué et en laisser un autre s’exécuter. L’événement de saisie rend le lecteur prêt ; une fois ordonnancé, il termine la procédure de retour.

L’entrée dans le noyau ajoute du travail par rapport à un appel de fonction normal : sauvegarder l’état, changer de privilège, vérifier les arguments et restaurer l’exécution. La mise en tampon par la bibliothèque peut regrouper de petites sorties en moins d’écritures. Sous Linux, strace ls exécute ls tout en affichant ses appels système, leurs arguments et leurs résultats.

Une entrée dans le noyau peut correspondre à une demande de service, à un problème d’instruction ou à un événement de périphérique. Classer la cause t’aide à prévoir ce que fera le système d’exploitation et si la même instruction doit être exécutée de nouveau.

Déterminer la cause de l’événement

Synchrone signifie lié à l’instruction en cours d’exécution. Cela ne signifie pas que les mêmes données provoquent exactement les mêmes fautes à chaque exécution. Un chargement peut provoquer une faute lorsque sa page est absente, puis réussir plus tard lorsque cette page est présente en mémoire. Asynchrone signifie que la cause de l’événement est indépendante de l’instruction courante, par exemple lorsqu’un disque termine un travail antérieur.

Les manuels des processeurs utilisent ces termes de différentes façons. Suis la cause : demande volontaire de service, événement provoqué par une instruction ou notification matérielle.

Transmettre au bon gestionnaire

Au démarrage, le système d’exploitation installe des adresses de gestionnaires protégées. Une table de déroutement ou d’interruption associe les types d’événements à des routines du noyau. Sur x86-64, la table des descripteurs d’interruption (IDT) sert aux interruptions et aux exceptions ; syscall utilise une adresse d’entrée dans un registre spécial du processeur. Seul le code privilégié peut configurer ces destinations.

Lors d’une interruption depuis le mode utilisateur, le matériel x86-64 sauvegarde un cadre de retour sur une pile noyau. Le code d’entrée sauvegarde des registres supplémentaires avant d’effectuer le travail. La voie syscall conserve son état de retour initial dans des registres et s’appuie sur le code d’entrée pour mettre en place la pile noyau. Considérer toutes les voies d’entrée comme des actions matérielles identiques masque une différence importante d’implémentation.

Choisir l’issue

Une page valide absente de la mémoire peut être chargée, après quoi l’instruction ayant provoqué la faute est exécutée de nouveau. Un accès à une mémoire que le processus ne peut pas utiliser conduit normalement Linux à envoyer SIGSEGV. Une exception n’est donc pas toujours fatale et ne demande pas toujours de sauter l’instruction courante.

Pour une véritable instruction entière idiv sur x86-64 avec un diviseur nul, le processeur déclenche une exception de division. Linux transmet normalement SIGFPE ; le message habituel mentionne les nombres à virgule flottante même pour cette instruction entière. La division entière sur AArch64 donne au contraire zéro pour un diviseur nul. En C, la division par zéro produit un comportement indéfini : un code C portable ne peut donc compter sur aucun de ces résultats matériels.

Lorsqu’une lecture sur disque se termine, le gestionnaire d’interruption enregistre sa fin et rend prêt le processus qui attendait. Ce processus peut s’exécuter plus tard. Une interruption d’horloge donne au système d’exploitation l’occasion de réexaminer quel processus utilise le processeur, mais le gestionnaire peut aussi revenir au même processus.

Distinguer un signal d’une interruption

Une interruption matérielle informe le processeur ; un signal informe un processus par l’intermédiaire du système d’exploitation. Une exception peut conduire le noyau à envoyer un signal, et un processus peut demander l’envoi d’un signal à un autre par kill. La fin normale d’une opération de périphérique donne lieu à une interruption sans impliquer d’erreur de programme.

Le code noyau doit aussi protéger les données partagées lorsque des événements se produisent. Il peut désactiver brièvement les interruptions sur un processeur et utiliser des verrous si nécessaire. De longues périodes pendant lesquelles les interruptions sont désactivées retardent le traitement des périphériques ; désactiver les seules interruptions locales n’empêche pas un autre processeur d’accéder aux données partagées.

Exécuter chaque instruction d’une application dans un simulateur logiciel rendrait le partage du processeur coûteux. Laisser une application contrôler la machine sans limite rendrait le partage dangereux. L’exécution directe limitée utilise l’exécution matérielle ordinaire avec une voie protégée de retour vers le système d’exploitation.

Résoudre deux problèmes de contrôle différents

L’exécution directe signifie que les instructions ordinaires d’un processus s’exécutent sur le processeur lui-même. Le système d’exploitation n’examine et n’approuve pas chaque instruction arithmétique. Deux problèmes subsistent : restreindre les opérations qui pourraient endommager la machine et reprendre le contrôle lorsqu’un programme ne s’arrête pas volontairement.

Le mode utilisateur résout le problème des restrictions. Les déroutements d’appel système permettent à un programme de demander des services sans choisir un code privilégié arbitraire. Une horloge matérielle résout le problème du contrôle : elle peut interrompre une application qui n’effectue aucun appel. Ensemble, ces mécanismes permettent de virtualiser le processeur avec un faible surcoût.

Préparer le système avant l’exécution des applications

Au démarrage, le noyau configure les gestionnaires d’événements et initialise l’horloge. Ces opérations de configuration sont privilégiées. Les programmes utilisateur exécutés ensuite ne peuvent pas rediriger les gestionnaires ni désactiver l’horloge pour éviter de perdre leur tour.

Pour démarrer un processus, le système d’exploitation crée son enregistrement de gestion et son image mémoire, prépare les arguments de démarrage et une pile utilisateur, et établit les valeurs initiales des registres. Il prépare un contexte sauvegardé initial afin que le chemin normal de retour du noyau vers le mode utilisateur puisse démarrer le programme. Conceptuellement, le processus commence par revenir d’un déroutement qu’il n’a jamais effectué.

L’organisation détaillée du cadre sauvegardé dépend du processeur et du système d’exploitation. L’idée de conception utile est la réutilisation : le même mécanisme de restauration peut reprendre un processus suspendu ou en démarrer un nouvellement préparé.

Revenir volontairement dans le noyau

Pendant un appel système, le matériel conserve l’état de retour initial et transfère le contrôle. Le code d’entrée du noyau sauvegarde les registres supplémentaires sur la pile noyau du processus. Après avoir exécuté une requête non bloquante, le noyau restaure le processus et revient en mode utilisateur. Si la requête bloque, un autre processus prêt peut s’exécuter en premier.

Lorsque main revient, le traitement de fin de l’environnement d’exécution demande finalement au noyau de terminer le processus. Sa mémoire peut être libérée tandis que son enregistrement de terminaison reste présent jusqu’à ce qu’un père le récupère.

Revenir sans coopération

Un système coopératif dépend des programmes pour effectuer des appels, céder le processeur ou provoquer des exceptions. Une boucle infinie qui ne fait rien de tout cela peut monopoliser un processeur. Le Mac OS classique illustre cette faiblesse.

Une architecture non coopérative utilise une interruption d’horloge pour forcer l’entrée dans le noyau. Considère un modèle pédagogique avec un processeur logique et une horloge périodique réglée sur 4 ms. L’horloge produit 1 000 / 4 = 250 impulsions par seconde. Un processus utilisateur coincé dans while (1) { } est interrompu à la prochaine impulsion. Le noyau peut alors exécuter un autre processus prêt ; la boucle n’a pas besoin d’atteindre d’abord un appel système.

L’impulsion est une occasion d’agir, pas une obligation de changer de processus. L’ordonnanceur peut laisser le processus interrompu continuer. Le traitement de l’horloge et la restauration de l’état sauvegardé sont des mécanismes ; le choix de l’ordonnanceur relève d’une politique. Le temps de réponse réel dépend aussi du travail du noyau et du moment où les interruptions peuvent être traitées : la période de l’horloge ne garantit donc pas à elle seule le temps de réponse d’une application.

L’entrée en mode noyau ne change pas nécessairement le processus en cours d’exécution. Une commutation de contexte se produit lorsque le noyau conserve l’état d’exécution d’un processus et reprend celui d’un autre. Cela exige à la fois la conservation de l’état utilisateur et un changement du contexte d’exécution propre au noyau.

Suivre la sortie de A et l’entrée de B

Pour une commutation déclenchée par l’horloge sur x86-64, suis les étapes :

1. A exécute des instructions utilisateur. L’horloge l’interrompt.
2. Le matériel passe en mode noyau et sauvegarde le cadre de retour d’interruption de A sur sa pile noyau. Le code d’entrée y sauvegarde les autres registres utilisateur de A.
3. L’ordonnanceur choisit B. La routine de commutation sauvegarde le contexte d’exécution noyau de A et restaure le contexte noyau sauvegardé de B, y compris son pointeur de pile noyau.
4. Le noyau passe au contexte d’espace d’adressage de B si nécessaire. Il s’exécute alors pour le compte de B en utilisant sa pile noyau.
5. Le code de sortie du noyau restaure les registres utilisateur de B. L’instruction de retour restaure l’état de retour de B et passe en mode utilisateur. B reprend là où il s’était arrêté.

La première sauvegarde conserve l’exécution utilisateur interrompue de A. La seconde conserve le point où en était le noyau pendant le traitement de A. Il ne s’agit pas de deux copies complètes identiques du même ensemble de registres. Un PCB ou une structure de contexte associée et la pile noyau propre au processus fonctionnent ensemble pour conserver l’état.

Identifier l’événement et la décision

Un appel bloquant, la terminaison d’un processus ou une décision prise à la suite d’une interruption d’horloge peuvent entraîner une commutation. Une interruption de périphérique peut rendre prêt un autre processus, que l’ordonnancement peut alors sélectionner. Tout le mécanisme de commutation s’exécute dans le noyau ; une application ne sauvegarde pas ses propres registres pour se porter volontaire à l’interruption.

Une commutation de contexte conserve l’état d’exécution nécessaire pour continuer. Le temps passe et le monde extérieur peut changer : les déplacements partagés dans les fichiers et les entrées externes ne sont pas figés pendant qu’un processus est suspendu.

Tenir compte des coûts directs et indirects

Le travail direct comprend l’exécution de l’ordonnanceur, la sauvegarde et la restauration des registres et la sélection d’un espace d’adressage. Les caches de traduction peuvent nécessiter une adaptation ; des traductions associées à un identifiant peuvent éviter de supprimer toutes les anciennes entrées. Des coûts indirects suivent lorsque B doit remplir à nouveau les caches du processeur ou les traductions d’adresses mises en cache que A a évincées. Le coût dépend du matériel et de la charge de travail : utilise donc des valeurs mesurées ou indiquées pour calculer le surcoût.

Supposons qu’une commutation, avec ses effets pertinents, coûte 5 µs et que les tours de calcul utile durent 10 ms. Convertis 10 ms en 10 000 µs. La part consacrée aux commutations est de 5 / (10 000 + 5), soit environ 0,05 %. Pour des tours utiles de 1 ms, elle est de 5 / 1 005, soit environ 0,50 % ; à 0,1 ms, elle est de 5 / 105, soit environ 4,8 %.

Le dénominateur comprend le travail utile et le temps de commutation pour un cycle répété. Un tour plus court peut multiplier les occasions d’effectuer du travail interactif, mais consacre une plus grande part aux commutations répétées. L’horloge et le code de commutation rendent possibles les tours courts ; la politique d’ordonnancement doit mettre ce coût en balance avec la réactivité.