Manpages

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 [AT] lists.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> ».