La fonction enveloppe clone()¶

Quand la fonction fn(arg) renvoie, le processus enfant se termine. La valeur entière renvoyée par fn est utilisée comme code de retour du processus enfant. Ce dernier peut également se terminer de manière explicite en invoquant la fonction exit(2) ou après la réception d'un signal fatal.

L'argument stack indique l'emplacement de la pile utilisée par le processus enfant. Comme les processus enfant et appelant peuvent partager de la mémoire, il n'est généralement pas possible pour l'enfant d'utiliser la même pile que son parent. Le processus appelant doit donc préparer un espace mémoire pour stocker la pile de son enfant, et transmettre à clone un pointeur sur cet emplacement. Les piles croissent vers le bas sur tous les processeurs implémentant Linux (sauf le HP PA), donc stack doit pointer sur la plus haute adresse de l'espace mémoire prévu pour la pile du processus enfant. Remarquez que clone() ne fournit aucun moyen pour que l'appelant puisse informer le noyau de la taille de la zone de la pile.

Les paramètres restant à clone() sont décrits ci-dessous.

clone3()¶

Comme avec fork(2), clone3() renvoie à la fois au parent et à l'enfant. Il renvoie 0 dans le processus enfant et il renvoie le PID de l'enfant dans le parent.

Le paramètre cl_args de clone3() est une structure ayant la forme suivante :

struct clone_args {
    u64 flags;        /* Masque de bit flags */
    u64 pidfd;        /* Où stocker le descripteur de fichier du PID
                         (pid_t *) */
    u64 child_tid;    /* Où stocker le TID de l'enfant,
                         dans la mémoire de l'enfant (pid_t *) */
    u64 parent_tid;   /* Où stocker le TID de l'enfant,
                         dans la mémoire du parent (int *) */
    u64 exit_signal;  /* Signal à envoyer au parent quand l'enfant se
                         termine */
    u64 stack;        /* Pointeur vers l'octet le plus faible de la pile */
    u64 stack_size;   /* Taille de la pile */
    u64 tls;          /* Emplacement du nouveau TLS */
};

Le paramètre size fourni à clone3() doit être initialisé à la taille de cette structure (l'existence du paramètre size autorise des extensions futures de la structure clone_args).

La pile du processus enfant est indiquée avec cl_args.stack, qui pointe vers l'octet le plus faible de la zone de la pile, et avec cl_args.stack_size, qui indique la taille de la pile en octets. Si l'attribut CLONE_VM est indiqué (voir ci-dessous), une pile doit être explicitement allouée et indiquée. Sinon, ces deux champs peuvent valoir NULL et 0, ce qui amène l'enfant à utiliser la même zone de pile que son parent (dans l'espace d'adressage virtuel de son propre enfant).

Les autres champs du paramètre cl_args sont abordés ci-dessous.

Équivalence entre les paramètres de clone() et de clone3()¶

Le tableau suivant montre l'équivalence entre les paramètres de clone() et les champs du paramètre clone_args fournis à clone3() :

Signal de fin de l'enfant¶

Le masque flags¶

Le masque flags est indiqué comme un OU bit à bit de zéro ou plus des constantes ci-dessous. Sauf explicitement indiqué, ces attributs sont disponibles (et ont le même effet) dans clone() et dans clone3().

CLONE_CHILD_CLEARTID (depuis Linux 2.5.49)

Effacer (zéro) l'ID du thread enfant situé là où pointe child_tid (clone()) ou cl_args.child_tid (clone3()) dans la mémoire de l'enfant lorsqu'il existe, et provoquer le réveil avec le futex à cette adresse. L'adresse concernée peut être modifiée par l'appel système set_tid_address(2). Cela est utilisé dans les bibliothèques de gestion de threads.

CLONE_CHILD_SETTID (depuis Linux 2.5.49)

Enregistrer l'ID du thread de l'enfant là où pointe child_tid ((clone()) ou cl_args.child_tid (clone3()) dans la mémoire de l'enfant. L'opération d'enregistrement se termine avant que l'appel clone ne redonne le contrôle à l'espace utilisateur dans le processus enfant (remarquez que l'opération d'enregistrement se termine avant que l'appel clone ne renvoie au processus parent, ce qui sera pertinent si l'attribut CLONE_VM est également utilisé).

CLONE_DETACHED (historique)

Pendant un moment (pendant la série de versions au cours du développement de Linux 2.5), il y a eu un attribut CLONE_DETACHED, avec lequel le parent ne recevait pas de signal quand l'enfant se terminait. Au final, l'effet de cet attribut a été inhibé par l'attribut CLONE_THREAD et quand Linux 2.6.0 a été publié, cet attribut n'avait pas d'effet. À partir de Linux 2.6.2, il n'a plus été nécessaire de fournir cet attribut avec CLONE_THREAD.

Cet attribut est toujours défini, mais il est généralement ignoré lors d'un appel clone(). Toutefois, voir la description de CLONE_PIDFD pour certaines exceptions.

CLONE_FILES (depuis Linux 2.0)

Si l'attribut CLONE_FILES est positionné, le processus appelant et le processus enfant partagent la même table de descripteurs de fichier. Tout descripteur créé par un processus est également valide pour l'autre processus. De même si un processus ferme un descripteur, ou modifie ses attributs (en utilisant l'opération fcntl(2) F_SETFD), l'autre processus en est aussi affecté. Si un processus qui partage une table de descripteurs de fichier appelle execve(2), sa table est dupliquée (non partagée).

Si CLONE_FILES n'est pas positionné, le processus enfant hérite d'une copie des descripteurs de fichier ouverts par l'appelant au moment de l'appel clone(). Les opérations d'ouverture et de fermeture ou de modification d'attributs du descripteur de fichier subséquentes, effectuées par le processus appelant ou son enfant, ne concernent pas l'autre processus. Remarquez toutefois que les copies des descripteurs de fichier dans l'enfant sont associées aux mêmes descriptions de fichiers ouverts que les descripteurs de fichier correspondants dans le processus appelant, partageant ainsi les attributs de position et d’états du fichier (consultez open(2)).

CLONE_FS (depuis Linux 2.0)

Si l'attribut CLONE_FS est positionné, le processus appelant et le processus enfant partagent les mêmes informations concernant le système de fichiers. Cela inclut la racine du système de fichiers, le répertoire de travail, et l'umask. Tout appel à chroot(2), chdir(2) ou umask(2) effectué par un processus aura également influence sur l'autre processus.

Si CLONE_FS n'est pas positionné, le processus enfant travaille sur une copie des informations de l'appelant concernant le système de fichiers au moment de l'appel clone. Les appels à chroot(2), chdir(2), umask(2) effectués ensuite par un processus n'affectent pas l'autre processus.

CLONE_IO (depuis Linux 2.6.25)

Si CLONE_IO est défini, alors le nouveau processus partage un contexte d'entrées-sorties avec le processus appelant. Si cet attribut n'est pas défini, alors (comme pour fork(2)) le nouveau processus a son propre contexte d'entrées-sorties.

Le contexte d'entrées-sorties correspond à la visibilité que l'ordonnanceur de disques a des entrées-sorties (c'est-à-dire, ce que l'ordonnanceur d'entrées-sorties utilise pour modéliser l'ordonnancement des entrées-sorties d'un processus). Si des processus partagent le même contexte d'entrées-sorties, ils sont traités comme un seul par l'ordonnanceur d'entrées-sorties. Par conséquent, ils partagent le même temps d'accès aux disques. Pour certains ordonnanceurs d'entrées-sorties, si deux processus partagent un contexte d'entrées-sorties, ils seront autorisés à intercaler leurs accès disque. Si plusieurs threads utilisent des entrées-sorties pour le même processus (aio_read(3), par exemple), ils devraient utiliser CLONE_IO pour obtenir de meilleurs performances d'entrées-sorties.

Si le noyau n'a pas été configuré avec l'option CONFIG_BLOCK, cet attribut n'a aucun effet.

CLONE_NEWCGROUP (depuis Linux 4.6)

Créer le processus dans un nouvel espace de noms cgroup. Si cet attribut n'est pas invoqué, alors (comme pour fork(2)) le processus est créé dans le même espace de noms cgroup que le processus appelant.

Pour plus d'informations sur les espaces de noms cgroup, consultez cgroup_namespaces(7).

Seul un processus disposant de privilèges (CAP_SYS_ADMIN) peut utiliser CLONE_NEWCGROUP.

CLONE_NEWIPC (depuis Linux 2.6.19)

Si CLONE_NEWIPC est invoqué, alors le processus est créé dans un nouvel espace de noms utilisateur IPC. Si cet attribut n'est pas invoqué, alors (comme pour fork(2)) le processus est créé dans le même espace de noms utilisateur IPC que le processus appelant.

Pour plus d'informations sur les espaces de noms IPC, reportez vous à ipc_namespaces(7).

Seul un processus disposant de privilèges (CAP_SYS_ADMIN) peut utiliser CLONE_NEWIPC. Cet attribut ne peut pas être employé en association avec CLONE_SYSVSEM.

CLONE_NEWNET (depuis Linux 2.6.24)

(L'implémentation de cet attribut n'est complète que depuis le noyau 2.6.29.)

Si CLONE_NEWNET est invoqué, alors le processus est créé dans un nouvel espace de noms réseau. Si cet attribut n'est pas invoqué, alors (comme pour fork(2)) le processus est créé dans le même espace de noms réseau que le processus appelant.

Pour plus d'informations sur les espaces de noms réseau, reportez vous à network_namespaces(7).

Seul un processus disposant de privilèges (CAP_SYS_ADMIN) peut appeler CLONE_NEWNET.

CLONE_NEWNS (depuis Linux 2.4.19)

Si l'attribut CLONE_NEWNS est invoqué, l'enfant cloné démarre dans un nouvel espace de noms montage, initialisé avec une copie de l'espace de noms du parent. Si CLONE_NEWNS n'est pas invoqué, alors l'enfant existe dans le même espace de noms montage que le parent.

Pour plus d'informations sur les espaces de noms montage, consultez namespaces(7) et mount_namespaces(7).

Seul un processus disposant de privilèges (CAP_SYS_ADMIN) peut utiliser l'attribut CLONE_NEWNS. Il n'est pas possible de spécifier à la fois CLONE_NEWNS et CLONE_FS pour le même appel clone.

CLONE_NEWPID (depuis Linux 2.6.24)

Si CLONE_NEWPID est invoqué, alors le processus est créé dans un nouvel espace de noms PID. Si cet attribut n'est pas invoqué, alors (comme pour fork(2)) le processus est créé dans le même espace de noms PID que le processus appelant.

Pour plus d'informations sur les espaces de noms PID, consultez namespaces(7) et pid_namespaces(7).

Seul un processus disposant de privilèges (CAP_SYS_ADMIN) peut utiliser CLONE_NEWPID. Cet attribut ne peut pas être utilisé en association avec CLONE_THREAD ou avec CLONE_PARENT.

CLONE_NEWUSER

(Cet attribut est apparu dans clone() pour la première fois dans Linux 2.6.23, les sémantiques actuelles de clone() ont été ajoutées dans Linux 3.5, et les derniers modules rendant les espaces de noms utilisateur complètement opérationnels sont apparus dans Linux 3.8.)

Si CLONE_NEWUSER est invoqué, alors le processus est créé dans un nouvel espace de noms utilisateur. Si cet attribut n'est pas invoqué, alors (comme pour fork(2)) le processus est créé dans le même espace de noms utilisateur que le processus appelant.

Pour plus d'informations sur les espaces de noms utilisateur, consultez namespaces(7) et user_namespaces(7).

Avant Linux 3.8, les processus appelant devaient disposer de trois capacités pour utiliser CLONE_NEWUSER : CAP_SYS_ADMIN, CAP_SETUID et CAP_SETGID. À partir de Linux 3.8, il n'est plus nécessaire de disposer de privilèges pour créer des espaces de noms utilisateur.

Cet attribut ne peut pas être utilisé en association avec CLONE_THREAD ou avec CLONE_PARENT. Pour des raisons de sécurité, CLONE_NEWUSER ne peut pas être utilisé en association avec CLONE_FS.

CLONE_NEWUTS (depuis Linux 2.6.19)

Si CLONE_NEWUTS est défini, créez le processus dans un nouvel espace de noms UTS, dont les identifiants sont initialisés en dupliquant les identifiants de l'espace de noms UTS du processus appelant. Si cet attribut n'est pas défini, alors (comme pour fork(2)) le processus est créé dans le même espace de noms UTS que le processus appelant.

Pour obtenir plus d'informations sur les espaces de noms UTS, consultez namespaces(7).

Seul un processus disposant de privilèges (CAP_SYS_ADMIN) peut utiliser CLONE_NEWUTS.

CLONE_PARENT (depuis Linux 2.3.12)

Si CLONE_PARENT est présent, le parent du nouvel enfant (comme il est indiqué par getppid(2)) sera le même que celui du processus appelant.

Si CLONE_PARENT n'est pas fourni, alors (comme pour fork(2)) le parent du processus enfant sera le processus appelant.

Remarquez que c'est le processus parent, tel qu'indiqué par getppid(2), qui est notifié lors de la fin de l'enfant. Ainsi, si CLONE_PARENT est présent, alors c'est le parent du processus appelant, et non ce dernier, qui sera notifié.

CLONE_PARENT_SETTID (depuis Linux 2.5.49)

Enregistrer l'ID du thread enfant à l'endroit vers lequel pointe parent_tid (clone()) ou cl_args.child_tid (clone3()) dans la mémoire du parent. (Dans Linux 2.5.32-2.5.48 il y a un attribut CLONE_SETTID qui fait cela.) L'opération d'enregistrement se termine avant que l'appel clone ne redonne le contrôle à l'espace utilisateur.

CLONE_PID (Linux 2.0 à 2.5.15)

Si l'attribut CLONE_PID est positionné, les processus appelant et enfant ont le même numéro de processus. C'est bien pour hacker le système, mais autrement il n'est plus utilisé. Depuis Linux 2.3.21, cet attribut ne peut être utilisé que par le processus de démarrage du système (PID 0). Il a disparu dans Linux 2.5.16. Si bien que le noyau ignorait silencieusement le bit s'il était indiqué dans le masque flags. Bien plus tard, le même bit a été recyclé pour être utilisé comme attribut de CLONE_PIDFD.

CLONE_PIDFD (depuis Linux 5.2)

Si cet attribut est indiqué, un descripteur de fichier PID renvoyant au processus enfant est alloué et placé à un endroit donné dans la mémoire du parent. L'attribut close-on-exec est positionné sur ce nouveau descripteur de fichier. Les descripteurs de fichier PID peuvent être utilisés pour des objectifs décrits dans pidfd_open(2).

Il n'est pas possible actuellement d'utiliser cet attribut avec CLONE_THREAD. Cela veut dire que le processus identifié par le descripteur de fichier PID sera toujours un leader dans le groupe de threads.

Si l'attribut obsolète CLONE_DETACHED est indiqué avec CLONE_PIDFD lors d'un appel à clone(), une erreur est renvoyée. Une erreur se produit aussi si CLONE_DETACHED est spécifié lors d'un appel à clone3(). Ce comportement garantit que le bit qui correspond à CLONE_DETACHED pourra être utilisé à l'avenir pour des fonctionnalités supplémentaires du descripteur de fichier PID.

CLONE_PTRACE (depuis Linux 2.2)

Si l'attribut CLONE_PTRACE est positionné et si l'appelant est suivi par un débogueur, alors l'enfant sera également suivi (consultez ptrace(2)).

CLONE_SETTLS (depuis Linux 2.5.32)

Le descripteur TLS (Thread Local Storage) est positionné sur tls.

L'interprétation de tls et les effets qui en découlent dépendent de l'architecture. Sur x86, tls est interprété comme une struct user_desc * (voir set_thread_area(2)). Sur x86-64, il s'agit de la nouvelle valeur à positionner pour le registre de base %fs (voir le paramètre ARCH_SET_FS de arch_prctl(2)). Sur les architectures ayant un registre TLS dédié, il s'agit de la nouvelle valeur de ce registre.

L'utilisation de cet attribut exige une connaissance détaillée et n'est généralement pas souhaitable, sauf dans l'implémentation de bibliothèques de gestion des threads.

CLONE_SIGHAND (depuis Linux 2.0)

Si l'attribut CLONE_SIGHAND est positionné, le processus appelant et le processus enfant partagent la même table de gestionnaires de signaux. Si l'appelant, ou l'enfant, appelle sigaction(2) pour modifier le comportement associé à un signal, ce comportement est également changé pour l'autre processus. Néanmoins, l'appelant et l'enfant ont toujours des masques de signaux distincts, et leurs ensembles de signaux bloqués sont indépendants. L'un des processus peut donc bloquer ou débloquer un signal en utilisant sigprocmask(2) sans affecter l'autre processus.

Si CLONE_SIGHAND n'est pas utilisé, le processus enfant hérite d'une copie des gestionnaires de signaux de l'appelant lors de l'invocation de clone(). Les appels à sigaction(2) effectués ensuite depuis un processus n'ont pas d'effets sur l'autre processus.

Depuis Linux 2.6.0, le masque flags doit aussi inclure CLONE_VM si CLONE_SIGHAND est spécifié

CLONE_STOPPED (depuis Linux 2.6.0)

Si l'attribut CLONE_STOPPED est positionné, l'enfant est initialement stoppé (comme s'il avait reçu le signal SIGSTOP), et doit être relancé en lui envoyant le signal SIGCONT.

Cet attribut a été rendu obsolète par Linux 2.6.25, puis il a été supprimé dans Linux 2.6.38. Depuis lors, le noyau l'ignore silencieusement sans erreur. À partir de Linux 4.6, le même bit a été réutilisé comme attribut de CLONE_NEWCGROUP.

CLONE_SYSVSEM (depuis Linux 2.5.10)

Si CLONE_SYSVSEM est positionné, l'enfant et le processus appelant partagent la même liste de compteurs « undo » pour les sémaphores System V (consultez semop(2)). Dans ce cas, cette liste regroupe toutes les valeurs semadj des processus partageant cette liste, et les modifications des sémaphores sont effectuées seulement lorsque le dernier processus de la liste se termine (ou cesse de partager la liste en invoquant unshare(2)). Si cet attribut n'est pas utilisé, l'enfant a une liste « undo » séparée, initialement vide.

CLONE_THREAD (depuis Linux 2.4.0)

Si CLONE_THREAD est présent, l'enfant est placé dans le même groupe de threads que le processus appelant. Afin de rendre l'explication de CLONE_THREAD plus lisible, le terme « thread » est utilisé pour parler des processus dans un même groupe de threads.

Les groupes de threads sont une fonctionnalité ajoutée dans Linux 2.4 pour supporter la notion POSIX d'ensemble de threads partageant un même PID. En interne, ce PID partagé est appelé identifiant de groupe de threads (TGID).Depuis Linux 2.4, l'appel getpid(2) renvoie l'identifiant du groupe de thread de l'appelant.

Les threads dans un groupe peuvent être distingués par leur identifiant de thread (TID, unique sur le système). Le TID d'un nouveau thread est renvoyé par clone() au processus appelant, et un thread peut obtenir son propre TID en utilisant gettid(2).

Quand clone est appelé sans positionner CLONE_THREAD, le nouveau thread est placé dans un nouveau groupe de thread dont le TGID est identique au TID du nouveau thread. Ce thread est le leader du nouveau groupe.

Un nouveau thread créé en utilisant CLONE_THREAD a le même processus parent que l'appelant de clone() (de même qu'avec CLONE_PARENT), ainsi les appels à getppid(2) renvoient la même valeur à tous les threads dans un même groupe. Lorsqu'un thread créé avec CLONE_THREAD termine, le thread qui a appelé clone() pour le créer ne reçoit pas le signal SIGCHLD (ou autre notification de terminaison) ; de même, l'état d'un tel thread ne peut pas être obtenu par wait(2). Le thread est dit détaché.

Lorsque tous les threads d'un groupe de threads terminent, le processus parent du groupe reçoit un signal SIGCHLD (ou autre indicateur de terminaison).

Si l'un des threads dans un groupe de threads appelle execve(2), tous les threads sauf le leader sont tués, et le nouveau programme est exécuté dans le leader du groupe de threads.

Si l'un des threads dans un groupe crée un enfant avec fork(2), n'importe lequel des threads du groupe peut utiliser wait(2) sur cet enfant.

Depuis Linux 2.5.35, le masque flags doit aussi inclure CLONE_SIGHAND si CLONE_THREAD est spécifié (et remarquez que depuis Linux 2.6.0, CLONE_SIGHAND a également besoin de CLONE_VM).

Les gestions de signaux sont définies au niveau des processus : si un signal sans gestionnaire est reçu par un thread, il affectera (tuera, stoppera, relancera, ou sera ignoré par) tous les membres du groupe de threads.

Chaque thread a son propre masque de signal, tel que défini par sigprocmask(2).

Un signal peut être adressé à un processus ou à un thread. S'il s'adresse à un processus, il cible un groupe de threads (c'est-à-dire un TGID), et il est envoyé à un thread choisi arbitrairement parmi ceux ne bloquant pas les signaux. Un signal peut s'adresser à un processus car il est généré par le noyau pour d'autres raisons qu'une exception matériel, ou parce qu'il a été envoyé en utilisant kill(2) ou sigqueue(3). Si un signal s'adresse à un thread, il cible (donc est envoyé) à un thread spécifique. Un signal peut s'adresser à un thread du fait d'un envoi par tgkill(2) ou pthread_sigqueue(3), ou parce que le thread a exécuté une instruction en langage machine qui a provoqué une exception matériel (comme un un accès invalide en mémoire, provoquant SIGSEGV, ou une exception de virgule flottante provoquant un SIGFPE).

Un appel à sigpending(2) renvoie un jeu de signaux qui réunit les signaux en attente adressés au processus et ceux en attente pour le thread appelant.

Si un signal adressé à un processus est envoyé à un groupe de threads, et si le groupe a installé un gestionnaire pour ce signal, alors le gestionnaire sera exécuté dans exactement un des membres du groupe de threads, choisi de façon arbitraire parmi ceux qui n'ont pas bloqué ce signal. Si plusieurs threads dans un groupe attendent le même signal en utilisant sigwaitinfo(2), le noyau choisira arbitrairement l'un d'entre eux pour recevoir le signal.

CLONE_UNTRACED (depuis Linux 2.5.46)

Si l'attribut CLONE_UNTRACED est positionné, alors un processus traçant le parent ne peut pas forcer CLONE_PTRACE pour cet enfant.

CLONE_VFORK (depuis Linux 2.2)

Si le bit CLONE_VFORK est actif, l'exécution du processus appelant est suspendue jusqu'à ce que l'enfant libère ses ressources de mémoire virtuelle par un appel execve(2) ou _exit(2) (comme avec vfork(2)).

Si CLONE_VFORK n'est pas indiqué, alors les deux processus sont ordonnancés à partir de la fin de l'appel, et l'application ne devrait pas considérer que l'ordre d'exécution est déterminé dans un ordre particulier.

CLONE_VM (depuis Linux 2.0)

Si le bit CLONE_VM est actif, le processus appelant et le processus enfant s'exécutent dans le même espace mémoire. En particulier, les écritures en mémoire effectuées par l'un des processus sont visibles par l'autre. De même toute projection en mémoire, ou toute suppression de projection, effectuée avec mmap(2) ou munmap(2) par l'un des processus affectera également l'autre processus.

Si CLONE_VM n'est pas actif, le processus enfant utilisera une copie distincte de l'espace mémoire de l'appelant au moment de l'appel clone. Les écritures ou les associations/désassociations de fichiers en mémoire effectuées par un processus n'affectent pas l'autre processus, comme cela se passe avec fork(2).

différences entre bibliothèque C et noyau¶

Contrairement à l'enveloppe de la glibc, l'appel système brut clone() accepte NULL en paramètre de stack (et de même, clone3() permet à cl_args.stack d'être NULL). Dans ce cas l'enfant utilise une copie de la pile du parent (la sémantique de copie-en-écriture assure que l'enfant recevra une copie indépendante des pages de la pile dès qu'un des deux processus la modifiera). Pour que cela fonctionne, il faut naturellement que CLONE_VM ne soit pas présent (si l'enfant partage la mémoire du parent du fait d'une utilisation de CLONE_VM, aucune duplication via la copie-en-écriture ne se produit et il peut s'ensuivre probablement un grand chaos).

L'ordre des paramètres change aussi dans l'appel système brut et des variations existent dans les paramètres en fonction des architectures, comme indiqué dans les paragraphes suivants.

L'interface de l'appel système brut sur des architectures x86-64 et quelques autres (dont sh, tile et alpha), est :

long clone(unsigned long flags, void *stack,
           int *parent_tid, int *child_tid,
           unsigned long tls);

Sur x86-32 et d'autres architectures classiques (dont score, ARM, ARM 64, PA-RISC, arc, Power PC, xtensa et MIPS), l'ordre des deux derniers paramètres est inversé :

long clone(unsigned long flags, void *stack,
          int *parent_tid, unsigned long tls,
          int *child_tid);

Sur les architectures cris et s390, l'ordre des deux premiers paramètres est inversé :

long clone(void *stack, unsigned long flags,
           int *parent_tid, int *child_tid,
           unsigned long tls);

Sur l'architecture microblaze, il existe un paramètre supplémentaire :

long clone(unsigned long flags, void *stack,
           int stack_size,         /* Taille de la pile */
           int *parent_tid, int *child_tid,
           unsigned long tls);

blackfin, m68k, et sparc¶

ia64¶

int __clone2(int (*fn)(void *), 
             void *stack_base, size_t stack_size,
             int flags, void *arg, ... 
          /* pid_t *parent_tid, struct user_desc *tls,
             pid_t *child_tid */ );

Le prototype présenté ci-dessus vaut pour la fonction enveloppe de la glibc ; pour l'appel système lui-même, il peut être décrit comme suit (il est identique au prototype clone() sur microblaze) :

long clone2(unsigned long flags, void *stack_base,
            int stack_size,         /* Taille de la pile */
            int *parent_tid, int *child_tid,
            unsigned long tls);

__clone2() fonctionne comme clone(), sauf que stack_base pointe sur la plus petite adresse de la pile de l'enfant et que stack_size indique la taille de la pile sur laquelle pointe stack_base.

Linux 2.4 et antérieurs¶

Source du programme¶

#define _GNU_SOURCE
#include <sys/wait.h>
#include <sys/utsname.h>
#include <sched.h>
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/mman.h>
#define errExit(msg)    do { perror(msg); exit(EXIT_FAILURE); \
                        } while (0)
static int              /* Commencer la fonction pour l'enfant cloné */
childFunc(void *arg)
{
    struct utsname uts;
    /* Modifier le nom d'hôte dans l'espace de noms UTS du
       processus enfant */
    if (sethostname(arg, strlen(arg)) == -1)
        errExit("sethostname");
    /* Récupérer et afficher le nom d'hôte */
    if (uname(&uts) == -1)
        errExit("uname");
    printf("uts.nodename dans l'enfant :  %s\n", uts.nodename);
    /* Rester en sommeil (fonction sleep) pour conserver l'espace
       de noms ouvert pendant un moment. Cela permet de réaliser
       quelques expérimentations — par exemple, un autre processus
       pourrait rejoindre l'espace de noms. */
    sleep(200);
    return 0;           /* Le processus enfant se termine à ce moment */
}
#define STACK_SIZE (1024 * 1024)    /* Taille de la pile pour
                                       l'enfant cloné */
int
main(int argc, char *argv[])
{
    char *stack;                    /* Début du tampon de la pile */
    char *stackTop;                 /* Fin du tampon de la pile */
    pid_t pid;
    struct utsname uts;
    if (argc < 2) {
        fprintf(stderr, "Utilisation : %s <nom_d_hôte-enfant>\n", argv[0]);
        exit(EXIT_SUCCESS);
    }
    /* Allouer la mémoire à utiliser pour la pile du processus enfant */
    stack = mmap(NULL, STACK_SIZE, PROT_READ | PROT_WRITE,
                 MAP_PRIVATE | MAP_ANONYMOUS | MAP_STACK, -1, 0);
    if (stack == MAP_FAILED)
        errExit("mmap");
    stackTop = stack + STACK_SIZE;  /* On suppose que la pile grandit vers
                                       le bas */
    /* Créer un processus enfant disposant de son propre
       espace de noms UTS ; le processus enfant débute
       son exécution dans childFunc() */
    pid = clone(childFunc, stackTop, CLONE_NEWUTS | SIGCHLD, argv[1]);
    if (pid == -1)
        errExit("clone");
    printf("clone() a renvoyé %ld\n", (long) pid);
    /* C'est ici que le processus parent échoue */
    sleep(1);           /* Laisser le temps au processus enfant de
                           changer son nom d'hôte */
    /* Afficher le nom d'hôte pour l'espace de noms UTS du processus parent.
       Celui-ci sera différent du nom d'hôte pour l'espace de noms UTS du
       processus enfant. */
    if (uname(&uts) == -1)
        errExit("uname");
    printf("uts.nodename dans le parent : %s\n", uts.nodename);
    if (waitpid(pid, NULL, 0) == -1)    /* Attendre le processus enfant */
        errExit("waitpid");
    printf("Fin du processus enfant\n");
    exit(EXIT_SUCCESS);
}