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.

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 man pages. However, some
probes provided by the syscall provider do not directly correspond to any
documented system call. There common reasons for this discrepancy are described in this
section.

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 UNIX 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 execve(2) is exece.

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

New System Calls

Oracle Solaris 11 implements the following system interfaces as individual system calls, unlike
Oracle Solaris 10 where some of them were not implemented at all and
the remainder were implemented as subcodes of a single private system call:

faccessat()

fchmodat()

fchownat()

fstatat()

linkat()

mkdirat()

mknodat()

openat()

readlinkat()

renameat()

symlinkat()

unlinkat()

These system calls implement a superset of the functionality of their old non-at-suffixed
counterparts. They take an additional first argument that is either an open directory
file descriptor, in which case the operation on a relative pathname is taken
relative to the specified directory, or is the reserved value AT_FDCWD, in which
case the operation takes place relative to the current working directory.

Deleted System Calls

In Oracle Solaris 11, the following old system calls have been removed from
the system. The libc interfaces remain, but they are reimplemented not as system
calls in their own right, but as calls to the new system calls
as indicated:

access(p, m)

faccessat(AT_FDCWD, p, m, 0)

chmod(p, m)

fchmodat(AT_FDCWD, p, m, 0)

chown(p, u, g)

fchownat(AT_FDCWD,
p, u, g, 0)

creat(p, m)

openat(AT_FDCWD, p, O_WRONLY | O_CREAT | O_TRUNC, m)

fchmod(fd,
m)

fchmodat(fd, NULL, m, 0)

fchown(fd, u, g)

fchownat(fd, NULL, u, g, 0)

fstat(fd, s)

fstatat(fd, NULL,
s, 0)

lchown(p, u, g)

fchownat(AT_FDCWD, p, u, g, AT_SYMLINK_NOFOLLOW)

link(p1, p2)

linkat(AT_FDCWD, p1, AT_FDCWD,
p2, 0)

lstat(p, s)

fstatat(AT_FDCWD, p, s, AT_SYMLINK_NOFOLLOW)

mkdir(p, m)

mkdirat(AT_FDCWD, p, m)

mknod(p, m. d)

mknodat(AT_FDCWD, p,
m, d)

open(p, o, m)

openat(AT_FDCWD, p, o, m)

readlink(p, b, s)

readlinkat(AT_FDCWD, p, b, s)

rename(p1,
p2)

renameat(AT_FDCWD, p1, AT_FDCWD, p2)

rmdir(p)

unlinkat(AT_FDCWD, p, AT_REMOVEDIR)

stat(p, s)

fstatat(AT_FDCWD, p, s, 0)

symlink(p1, p2)

symlinkat(p1, AT_FDCWD,
p2)

unlink(p)

unlinkat(AT_FDCWD, p, 0)

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 man pages. Each of these large file system call interfaces
appears as its own syscall probe as shown in Table 11-8.

Table 11-8 sycall Large File Probes

Large File syscall Probe

System Call

fstatat64

fstatat(2)

fstatvfs64

fstatvfs(2)

getdents64

fgetdents(2)

getrlimit64

getrlimit(2)

mmap64

mmap(2)

openat64

openat(2)

pread64

pread(2)

pwrite64

pwrite(2)

setrlimit64

setrlimit(2)

statvfs64

statvfs(2)

Private System Calls

Some system calls are private implementation details of Oracle Solaris subsystems that span
the user-kernel boundary. As such, these system calls do not have man 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).

Arguments

For entry probes, the arguments (arg0 .. argn) 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.

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
Chapter 18, Stability.