syscall Provider
The syscall
provider makes available a probe at the
entry to and return from every system call in the system. Because system calls
are the primary interface between user-level applications and the operating
system kernel, the syscall
provider can offer tremendous
insight into application behavior with respect to the system.
21.1. Probes
syscall
provides a pair of probes for each
system call: an entry
probe that fires before the system
call is entered, and a return
probe that fires after the
system call has completed but before control has transferred back to user-level.
For all syscall
probes, the function name is set to be
the name of the instrumented system call and the module name is undefined.
The names of the system calls as provided by the syscall
provider
may be found in the /etc/name_to_sysnum file. Often,
the system call names provided by syscall
correspond to
names in Section 2 of the manual pages. However, some probes provided by the syscall
provider do not directly correspond to any documented system
call. The common reasons for this discrepancy are described in
this section.
21.1.1. System Call Anachronisms
In some cases, the name of the system call as provided by the syscall
provider is actually a reflection of an ancient implementation
detail. For example, for reasons dating back to UNIXTM antiquity,
the name of exit(2) in /etc/name_to_sysnum
is rexit
. Similarly, the
name of time(2) is gtime
, and the name of both execle(2) and execve(2) is exece
.
21.1.2. Subcoded System Calls
Some system calls as presented in Section 2 are implemented as suboperations
of an undocumented system call. For example, the system calls related to System
V semaphores (semctl(2), semget(2), semids(2), semop(2), and semtimedop(2)) are implemented as suboperations
of a single system call, semsys
. The semsys
system
call takes as its first argument an implementation-specific subcode denoting
the specific system call required: SEMCTL
, SEMGET
, SEMIDS
, SEMOP
or SEMTIMEDOP
,
respectively. As a result of overloading a single system call to implement
multiple system calls, there is only a single pair of syscall probes for System
V semaphores: syscall::semsys:entry
and syscall::semsys:return
.
21.1.3. Large File System Calls
A 32-bit program that supports large
files that exceed four gigabytes in size must be able to process
64–bit file offsets. Because large files require use of large offsets,
large files are manipulated through a parallel set of system interfaces, as
described in lf64(5).
These interfaces are documented in lf64
, but they do not
have individual manual pages. Each of these large file system call interfaces
appears as its own syscall
probe as shown in syscall Large File Probes.
Large File |
System Call |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
21.1.4. Private System Calls
Some system calls are private implementation details of illumos subsystems
that span the user-kernel boundary. As such, these system calls do not have
manual pages in Section 2. Examples of system calls in this category include
the signotify
system call, which is used as part of the
implementation of POSIX.4 message queues, and the utssys
system
call, which is used to implement fuser(1M).
21.2. Arguments
For entry
probes, the arguments
(arg0
.. arg
n)
are the arguments to the system call. For
return
probes,
both arg0
and arg1
contain the return
value. A non-zero value in the D variable errno
indicates
system call failure.
21.3. Stability
The syscall
provider
uses DTrace's stability mechanism to describe its stabilities as shown in
the following table. For more information about the stability mechanism, refer
to Stability.
Element |
Name stability |
Data stability |
Dependency class |
---|---|---|---|
Provider |
Evolving |
Evolving |
Common |
Module |
Private |
Private |
Unknown |
Function |
Unstable |
Unstable |
ISA |
Name |
Evolving |
Evolving |
Common |
Arguments |
Unstable |
Unstable |
ISA |