syscalls - Appels système de Linux
L'appel système est l'interface fondamentale entre une
application et le noyau Linux.
Appels système et fonctions de bibliothèque
Les appels système ne sont en général pas
appelés directement, mais à partir de fonctions enveloppe de
la glibc (ou d'une autre bibliothèque). Pour avoir des détails
pour l'appel direct d'un appel système, consultez intro(2).
Souvent, mais pas toujours, le nom de la fonction enveloppe est le
même que celui de l'appel système à invoquer. Par
exemple, la glibc contient une fonction chdir() qui invoque l'appel
système « chdir » sous-jacent.
Souvent, la fonction enveloppe de la glibc est très petite,
ne faisant que très peu en plus de placer les paramètres dans
les bons registres avant d'appeler l'appel système puis de
positionner errno comme il faut une fois que l'appel système a
rendu la main. (Ce sont les mêmes étapes qui sont
effectuées par syscall(2), qui peut être utilisé
pour les appels système pour lesquels il n'y a pas de fonction
enveloppe de fournies.) Note : les appels système indiquent un
échec en renvoyant un numéro d'erreur négatif à
l'appelant sur les architectures n'ayant pas de registre ou d'attribut
d'erreur séparé comme noté dans
syscall(2) ; quand cela arrive, la fonction enveloppe prend
l'opposé du numéro d'erreur (pour le rendre positif), le copie
dans errno et renvoie -1 à l'appelant de la fonction
enveloppe.
Des fois, cependant, la fonction réalise certaines
opérations avant d'invoquer l'appel système. Par exemple, de
nos jour il y a deux appels système truncate(2) et
truncate64(2) (pour les raisons données ci-dessous) et la
fonction truncate() de la glibc vérifie quels appels
système sont fournis par le noyau et détermine lequel doit
être utilisé.
Voici une liste des appels système Linux. Dans cette liste,
la colonne Noyau indique la version du noyau dans laquelle ils sont
apparus, s'ils sont apparu dans la version 2.2 de Linux ou
après. Remarquez les points suivants :
- Si aucune version de noyau n'est indiquée, l'appel système
est apparu dans Linux 1.0 ou auparavant.
- Quand un appel système est marqué
« 1.2 », cela signifie que l'appel
système est probablement apparu dans une version 1.1.x du noyau
Linux et est apparu la première fois dans un noyau stable dans la
version 1.2. (Le développement du noyau Linux 1.2 a
débuté à partir d'une branche de Linux 1.0.6,
au travers de la série « non stable »
des noyaux Linux 1.1.x.)
- Quand un appel système est marqué
« 2.0 », cela signifie que l'appel
système est probablement apparu dans une version 1.3.x du
noyau Linux et est apparu la première fois dans un noyau stable
dans Linux 2.0. (Le développement du noyau Linux 2.0
a débuté à partir d'une branche de
Linux 1.2.x, aux alentours de la branche 1.2.10, au travers
de la série « non stable » des noyaux
Linux 1.3.x.)
- Quand un appel système est marqué
« 2.2 », cela signifie que l'appel
système est probablement apparu dans une version 2.1.x du
noyau Linux et est apparu la première fois dans un noyau stable
dans Linux 2.2.0. (Le développement du noyau
Linux 2.2 a débuté à partir d'une branche de
Linux 2.0.21, au travers de la série « non
stable » des noyaux Linux 2.1.x.)
- Quand un appel système est marqué
« 2.4 », cela signifie que l'appel
système est probablement apparu dans une version 2.3.x du
noyau Linux et est apparu la première fois dans un noyau stable
dans Linux 2.4.0. (Le développement du noyau
Linux 2.4 a débuté à partir d'une branche de
Linux 2.2.8 au travers de la série « non
stable » des noyaux Linux 2.3.x.)
- Quand un appel système est marqué
« 2.6 », cela signifie que l'appel
système est probablement apparu dans une version 2.5.x du
noyau Linux et est apparu la première fois dans un noyau stable
dans Linux 2.6.0. (Le développement du noyau
Linux 2.6 a débuté à partir d'une branche de
Linux 2.4.15 au travers de la série « non
stable » des noyaux Linux 2.5.x.)
- À partir de Linux 2.6.0, le mode de développement a
changé et de nouveaux appels système pouvaient
apparaître à chaque version de Linux 2.6.x. Dans ce
cas, le numéro de version exact où l'appel système
est apparu est indiqué. Cette convention continue de s'appliquer
à la série des noyaux Linux 3.x, qui ont
succédé au noyau Linux 2.6.39, à la
série des noyaux Linux 4.x qui ont succédé au
noyau Linux 3.19, à la série des noyaux
Linux 5.x qui ont succédé au noyau Linux 4.20
et à la série des noyaux Linux 6.x qui ont
succédé au noyau Linux 5.19.
- Dans certains cas, un appel système a été
ajouté à un noyau de la série stable après
l'embranchement provenant de la série stable
précédente, puis a été porté dans les
séries stables précédentes du noyau. Par exemple
certains appels système apparus dans Linux 2.6.x ont
été rétroportés dans les publications
Linux 2.4.x postérieures à Linux 2.4.15. Dans ce cas,
les deux versions des deux séries majeures du noyau dans lesquelles
l'appel système est apparu sont mentionnées.
La liste des appels système qui sont disponibles dans la
version 5.14 (ou dans certains cas, uniquement pour certains noyaux
plus anciens) est la suivante :
Sur de nombreuses plates-formes, y compris les x86-32, les appels
de socket sont multiplexés (par des fonctions de la glibc) à
travers socketcall(2) et de même les IPC System V
à l’aide d’ipc(2).
Même si des entrées ont été
réservées dans la table des appels système, les appels
système suivants ne sont pas implémentés dans le noyaux
standard : afs_syscall(2), break(2), ftime(2),
getpmsg(2), gtty(2), idle(2), lock(2),
madvise1(2), mpx(2), phys(2), prof(2),
profil(2), putpmsg(2), security(2), stty(2),
tuxcall(2), ulimit(2) et vserver(2) (voir aussi
unimplemented(2)). Toutefois, ftime(3), profil(3) et
ulimit(3) sont disponibles sous forme de fonctions de
bibliothèque. L'entrée pour phys(2) est utilisée
pour umount(2) depuis Linux 2.1.116, phys(2) ne sera
jamais implémenté. Les appels getpmsg(2) et
putpmsg(2) sont pour les noyaux modifiés qui supportent les
FLUX et ne seront peut-être jamais dans le noyau standard.
set_zone_reclaim(2) a existé
brièvement : ajouté dans Linux 2.6.13, et
retiré dans Linux 2.6.16. Cet appel système n'a jamais
été disponible dans l'espace utilisateur.
En général, le code implémentant l'appel
système ayant le numéro __NR_xxx dans le fichier
/usr/include/asm/unistd.h se trouve dans la routine sys_xxx()
du source du noyau Linux. Il y a néanmoins plusieurs exceptions,
principalement lorsque d'anciens appels système ont été
remplacés par des nouveaux. Ces cas n'ont pas été
traités de manière homogène. Sur les plate-formes avec
une émulation de système propriétaire, comme sparc,
sparc64 et alpha, il existe de nombreux appels
supplémentaires ;mips64 contient aussi un jeu complet d'appels
système 32 bits.
Avec le temps, des changements dans les interfaces de certains
appels système ont été nécessaires. Une raison
pour ces changements a été le besoin d'augmenter la taille des
structures ou des valeurs scalaires passées aux appels
système. À cause de ces changements, certaines architectures
(particulièrement des vieilles architectures 32 bits comme
i386) ont maintenant divers groupes d'appels système
apparentés (par exemple truncate(2) et truncate64(2))
qui remplissent des tâches similaires mais qui varient sur des
détails comme la taille de leurs paramètres. (Comme
noté précédemment, les applications ne sont
généralement pas conscientes de cela : les fonctions
enveloppe de la glibc remplissent certaines tâches pour s'assurer que
c'est le bon appel système qui est appelé et la
compatibilité de l'ABI est préservée avec les vieux
binaires.) Voici des exemples d'appels système qui existent dans
plusieurs versions :
- À ce jour, il y a trois versions de stat(2) :
sys_stat() (entrée __NR_oldstat),
sys_newstat() (entrée __NR_stat) et
sys_stat64() (entrée __NR_stat64), la dernière
étant celle utilisée actuellement. La même histoire
s'applique à lstat(2) et fstat(2).
- De même, les définitions __NR_oldolduname,
__NR_olduname et __NR_uname concernent les routines
sys_olduname(), sys_uname() et sys_newuname().
- Dans Linux 2.0, une nouvelle version de vm86(2) est apparue,
l'ancienne et la nouvelle routine du noyau étant appelées
sys_vm86old() et sys_vm86().
- Dans Linux 2.4, une nouvelle version de getrlimit(2) est
apparue, l'ancienne et la nouvelle routine du noyau étant
appelées sys_old_getrlimit() (entrée
__NR_getrlimit) et sys_getrlimit() (entrée
__NR_ugetrlimit).
- Linux 2.4 a augmenté la taille des identifiants
d'utilisateur et de groupe de 16 bits à 32 bits. Pour
permettre ce changement, un jeu d'appels système ont
été ajoutés (par exemple, chown32(2),
getuid32(2), getgroups32(2), setresuid32(2)),
surchargeant les précédents appels système du
même nom n'ayant pas le suffixe
« 32 ».
- Linux 2.4 a ajouté la gestion des gros fichiers pour les
applications sur architecture 32 bits (c'est-à-dire la
gestion des fichiers dont la taille et les décalages dans le
fichier ne peuvent pas être représentés sur
32 bits). Pour gérer ce changement, des appels
système, qui utilisent des décalages et des tailles de
fichiers, ont dû être remplacés. Ainsi, les appels
système suivants ont été ajoutés :
fcntl64(2), getdents64(2), stat64(2),
statfs64(2), truncate64(2) et leurs appels système
analogues qui fonctionnent avec des descripteurs de fichier ou des liens
symboliques. Ces appels système remplacent les anciens appels
système qui, sauf pour les appels
« stat », ont le même nom sans le
suffixe « 64 ».
- Sur les plates-formes récentes qui n'ont que des accès aux
fichiers 64 bits et des UID ou GID 32 bits (par exemple
alpha, ia64, s390x, x86-64), il y a une seule version des appels
système pour l'accès aux fichiers, UID ou GID. Sur les
plates-formes (habituellement des plates-formes 32 bits) où
les les appels *64 et *32 existent, les autres versions sont
obsolètes.
- Les appels rt_sig* ont été ajoutés dans Linux
2.2 pour gérer l'ajout des signaux temps réel (consultez
signal(7)). Ces appels système remplacent les appels
précédents de mêmes noms sans le préfixe
« rt_ ».
- Les appels système select(2) et mmap(2) utilisent
cinq paramètres ou plus, ce qui a posé des problèmes
avec les méthodes classiques de passage de paramètres sur
i386. Ainsi, alors que les autres architectures disposent de
sys_select() et sys_mmap() correspondant à
__NR_select et __NR_mmap, on trouve sur les i386
old_select() et old_mmap() (des routines utilisant un
pointeur vers un bloc de paramètres) à leur place. De nos
jours, passer cinq paramètres n'est plus un problème, et il
existe donc un __NR__newselect correspondant directement à
sys_select() ; il en est de même pour
__NR_mmap2. s390x est la seule architecture 64 bits qui a
old_mmap().
- getxgid(2)
- renvoie une paire de GID et de GID effectif au moyen des registres
r0 et r20 ; il est fourni à la place de
getgid(2) et getegid(2).
- getxpid(2)
- renvoie une paire de PID et de PID parent au moyen des registres r0
et r20 ; il est fourni à la place de getpid(2)
et getppid(2).
- old_adjtimex(2)
- est une variante de adjtimex(2) qui utilise struct
timeval32, pour une compatibilité avec OSF/1.
- getxuid(2)
- renvoie une paire de GID et de GID effectif au moyen des registres
r0 et r20 ; il est fourni à la place de
getuid(2) et geteuid(2).
- sethae(2)
- est utilisé pour configurer le registre Host Address Extension sur
les systèmes Alpha bon marché afin d'accéder à
l'espace d'adresses au-delà des 27 premiers bits.
La traduction française de cette page de manuel a
été créée par Christophe Blaess
<https://www.blaess.fr/christophe/>, Stéphan Rafin
<stephan.rafin@laposte.net>, Thierry Vignaud
<tvignaud@mandriva.com>, François Micaux, Alain Portal
<aportal@univ-montp2.fr>, Jean-Philippe Guérard
<fevrier@tigreraye.org>, Jean-Luc Coulon (f5ibh)
<jean-luc.coulon@wanadoo.fr>, Julien Cristau
<jcristau@debian.org>, Thomas Huriaux
<thomas.huriaux@gmail.com>, Nicolas François
<nicolas.francois@centraliens.net>, Florentin Duneau
<fduneau@gmail.com>, Simon Paillard
<simon.paillard@resel.enst-bretagne.fr>, Denis Barbier
<barbier@debian.org>, David Prévot <david@tilapin.org> et
Jean-Pierre Giraud <jean-pierregiraud@neuf.fr>
Cette traduction est une documentation libre ; veuillez
vous reporter à la
GNU General
Public License version 3 concernant les conditions de copie et de
distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.
Si vous découvrez un bogue dans la traduction de cette page
de manuel, veuillez envoyer un message à
debian-l10n-french@lists.debian.org.