Chapitre 21 Fournisseur syscall

Grâce au fournisseur syscall une sonde est disponible à l'activation et au retour de chaque appel système au sein du système. Comme les appels système sont l'interface principale entre les applications de niveau utilisateur et le noyau du système d'exploitation, le fournisseur syscall peut conférer une connaissance intuitive considérable sur le comportement de l'application relatif au système.

Sondes

syscall fournit une paire de sondes pour chaque appel système : une sonde entry qui se déclenche avant l'activation de l'appel système et une sonde return qui se déclenche après la désactivation de l'appel système mais avant le transfert du contrôle au niveau utilisateur. Quelle que soit la sonde syscall, le nom de la fonction est configuré de manière à correspondre au nom de l'appel système instrumenté et le nom du module est indéfini.

Le nom des appels système tel qu'indiqué par le fournisseur syscall figure normalement dans le fichier /etc/name_to_sysnum. En règle générale, les noms d'appel système fournis par syscall correspondent aux noms figurant dans la Section 2 des pages de manuel. Cependant, certaines sondes fournies par syscall ne correspondent pas directement à un appel système documenté. Cette section en présente les raisons classiques.

Anachronismes des appels système

Dans certains cas, le nom de l'appel système fourni par syscall reflète en fait un précédent détail d'implémentation. Par exemple, pour des motifs remontant aux prémices d'UNIX^TM, le nom de exit(2) dans /etc/name_to_sysnum est rexit. De même, le nom de time(2) est gtime et le nom de execle(2) et execve(2) est exece.

Appels système sous-codés

Certains appels système (voir Section 2 pour des exemples) sont implémentés sous la forme de sous-opérations d'un appel système non documenté. Par exemple, les appels système se rapportant aux sémaphores du System V (semctl(2), semget(2), semids(2), semop(2) et semtimedop(2)) sont implémentés en tant que sous-opérations d'un seul appel système, semsys. L'appel système semsys prend comme premier argument un sous-code spécifique à l'implémentation indiquant l'appel système spécifique requis : SEMCTL, SEMGET, SEMIDS, SEMOP ou SEMTIMEDOP, respectivement. En cas de surcharge d'un seul appel système pour implémenter plusieurs appels système, il n'y a qu'une seule paire de sondes syscall pour les sémaphores du System V : syscall::semsys:entry et syscall::semsys:return .

Appels système de grands fichiers

Un programme 32 bits qui prend en charge de grands fichiers dont la taille excède quatre giga-octets doit pouvoir traiter des décalages de fichiers 64–bits. Comme les grands fichiers impliquent de grands décalages, ils sont manipulés par le biais d'un ensemble parallèle d'interfaces système, comme indiqué dans lf64(5). Ces interfaces sont documentées dans lf64 mais aucune page de manuel individuelle n'est spécifiquement dédiée à leur présentation. Chacune de ces interfaces d'appel système de grands fichiers possède sa propre sonde syscall comme illustré dans le Tableau 21–1.

Tableau 21–1 syscall Sonde de grands fichiers

Sonde syscall de grands fichiers	Appel système
creat64	creat(2)
fstat64	fstat(2)
fstatvfs64	fstatvfs(2)
getdents64	getdents(2)
getrlimit64	getrlimit(2)
lstat64	lstat(2)
mmap64	mmap(2)
open64	open(2)
pread64	pread(2)
pwrite64	pwrite(2)
setrlimit64	setrlimit(2)
stat64	stat(2)
statvfs64	statvfs(2)

Appels système privés

Certains appels système constituent des détails d'implémentation privée de sous-systèmes Solaris qui forment la limite du noyau utilisateur. C'est pourquoi, ces appels système ne font l'objet d'aucune page de manuel dans la Section 2. Cette catégorie comprend notamment l'appel système signotify qui entre dans le cadre de l'implémentation des files d'attente de messages de POSIX.4 et l'appel système utssys qui permet d'implémenter fuser(1M).

Arguments

Pour les sondes entry , les arguments (arg0 .. argn) correspondent aux arguments de l'appel système. Pour les sondes return, arg0 et arg1 contiennent la valeur de retour. Une valeur non-zéro dans une variable en D errno indique un échec de l'appel système.

Stabilité

Le fournisseur syscall utilise le mécanisme de stabilité de DTrace pour décrire sa stabilité, comme illustré dans le tableau suivant. Pour plus d'informations sur le mécanisme de stabilité, reportez-vous au Chapitre39Stabilité.

Élément	Stabilité des noms	Stabilité des données	Classe de dépendance
Fournisseur	En cours d'évolution	En cours d'évolution	Commune
Module	Privé	Privé	Inconnu
Fonction	Instable	Instable	ISA
Nom	En cours d'évolution	En cours d'évolution	Commune
Arguments	Instable	Instable	ISA