NOM¶
syscalls - Appels système de Linux
SYNOPSIS¶
Appels système de Linux.
DESCRIPTION¶
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é
directement, mais à partir de fonctions 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 de la bibliothèque est le même que celui de l'appel
système à invoquer. Par exemple, la fonction
truncate() de la
glibc invoque l'appel système « truncate »
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 ; quand ça arrive, la fonction enveloppe prend
l'opposé du numéro d'erreur (pour le rendre positif), le copie dans
errno et renvoie -1 pour 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é.
Liste des appels système¶
Cette page de manuel liste ces appels système qui sont communs à la
plupart des plates-formes. Dans cette liste, la colonne
Noyau indique
la version du noyau pour laquelle ils sont apparus, s'ils sont apparu
après la version 2.2 de Linux. Notez les points suivants :
- *
- Si aucune version de noyau n'est indiquée, l'appel
système est apparu dans le noyau 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 et est apparu la
première fois dans un noyau stable dans la version 1.2. (Le
développement du noyau 1.2 a débuté à partir d'une
branche de la version 1.0.6 du noyau, au travers de la série
« non stable » des noyaux 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 et est apparu la
première fois dans un noyau stable dans la version 2.0. (Le
développement du noyau 2.0 a débuté à partir d'une
branche de la version 1.2.x du noyau, vers la version 1.2.10, au travers
de la série « non stable » des noyaux
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 et est apparu la
première fois dans un noyau stable dans la version 2.2.0. (Le
développement du noyau 2.2 a débuté à partir d'une
branche de la version 2.0.21 du noyau, au travers de la série
« non stable » des noyaux 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 et est apparu la
première fois dans un noyau stable dans la version 2.4.0. (Le
développement du noyau 2.4 a débuté à partir d'une
branche de la version 2.2.8 du noyau, au travers de la série
« non stable » des noyaux 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 et est apparu la
première fois dans un noyau stable dans la version 2.6.0. (Le
développement du noyau 2.6 a débuté à partir d'une
branche de la version 2.4.15 du noyau, au travers de la série
« non stable » des noyaux 2.5.x.)
- *
- A partir du noyau 2.6.0, le mode de développement a
changé et de nouveaux appels système pourraient apparaître
à chaque version 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 3.x, qui ont
succédé au noyau 2.6.39.
- *
- 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 la série stable
précédente du noyau. Par exemple certains appels système
apparus dans 2.6.x ont été portés dans une version 2.4.x
postérieure à la version 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 3.5
(ou dans certains cas pour certaines versions plus anciennes du noyau) est la
suivante\ :
Sur de nombreuses plates-formes, y compris les i386, les appels des sockets sont
multiplexés (par des fonctions de la glibc) à travers
socketcall(2) et de même les IPC System V via
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 :
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 le 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é en 2.6.16. Cet appel système n'a jamais
été disponible dans l'espace utilisateur.
NOTES¶
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 noyau Linux. (La table de
distribution pour la version i386 se trouve dans
/usr/src/linux/arch/i386/kernel/entry.S.) 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 parisc, 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é l'augmentation de la taille des structures ou des
valeurs scalaires passées aux appels système. À cause de ces
changements, il y a maintenant plusieurs implémentations de certains
appels système (par exemple
truncate(2) et
truncate64(2)).
Ces différentes versions ne sont pas compatibles au niveau binaire, mais
les applications ne sont généralement pas impactées par
ceci : la magie de la glibc fait en sorte que les binaires existants
utilisent la version des appels système qui existaient au moment où
le binaire a été créé. Ainsi la compatibilité de
l'ABI est préservée. 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 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 sans 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 des 32 bits). Pour
gérer ce changement, des appels système, qui utilisent des
déplacements dans des fichiers ou des tailles de fichiers, ont
dû être remplacés. Ainsi, les appels système suivants
ont été ajoutés : fcntl64(2),
ftruncate64(2), getdents64(2), stat64(2),
statfs64(2) et les 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 « stats », 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 32-bits (ex. alpha, ia64, s390x) il n'y a pas
d'appel *64 ou *32. Quand les appels *64 et *32 existent, les autres
versions sont obsolètes.
- *
- Les appels rt_sig* ont été ajoutés
dans le noyau 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 du même nom sans le préfixe
« rt_ ».
- *
- Les appels système select(2) et mmap(2)
utilisent 5 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() à leur place. Ce sont des routines utilisant un
pointeur sur un bloc de paramètres. De nos jours, passer 5
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.
VOIR AUSSI¶
syscall(2),
unimplemented(2),
libc(7)
COLOPHON¶
Cette page fait partie de la publication 3.44 du projet
man-pages Linux.
Une description du projet et des instructions pour signaler des anomalies
peuvent être trouvées à l'adresse
<
http://www.kernel.org/doc/man-pages/>.
TRADUCTION¶
Depuis 2010, cette traduction est maintenue à l'aide de l'outil po4a
<
http://po4a.alioth.debian.org/> par l'équipe de traduction
francophone au sein du projet perkamon
<
http://perkamon.alioth.debian.org/>.
Christophe Blaess <
http://www.blaess.fr/christophe/> (1996-2003), Alain
Portal <
http://manpagesfr.free.fr/> (2003-2006). Julien Cristau et
l'équipe francophone de traduction de Debian (2006-2009).
Veuillez signaler toute erreur de traduction en écrivant à
<debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le
paquet
manpages-fr.
Vous pouvez toujours avoir accès à la version anglaise de ce document
en utilisant la commande «
man -L C
<section> <page_de_man> ».