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¶
Voici une liste des appels système Linux. 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. Remarquez 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.14 (ou dans certains cas pour certaines versions plus
anciennes du noyau) est la suivante :
Sur de nombreuses plates-formes, y compris les x86-32, les appels des sockets
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 :
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 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¶
intro(2),
syscall(2),
unimplemented(2),
libc(7),
vdso(7)
COLOPHON¶
Cette page fait partie de la publication 3.65 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> ».