The system call is the fundamental interface between an application
and the Linux kernel.
System calls and library wrapper functions
System calls are generally not invoked directly,
but rather via wrapper functions in glibc (or perhaps some other library).
For details of direct invocation of a system call, see
intro(2).
Often, but not always, the name of the wrapper function is the same
as the name of the system call that it invokes.
For example, glibc contains a function
truncate()
which invokes the underlying "truncate" system call.
Often the glibc wrapper function is quite thin, doing little work
other than copying arguments to the right registers
before invoking the system call,
and then setting
errno
appropriately after the system call has returned.
(These are the same steps that are performed by
syscall(2),
which can be used to invoke system calls
for which no wrapper function is provided.)
Note: system calls indicate a failure by returning a negative error
number to the caller;
when this happens,
the wrapper function negates the returned error number
(to make it positive), copies it to
errno,
and returns -1 to the caller of the wrapper.
Sometimes, however, the wrapper function does some extra work
before invoking the system call.
For example, nowadays there are (for reasons described below) two
related system calls,
truncate(2)
and
truncate64(2),
and the glibc
truncate()
wrapper function checks which of those system calls
are provided by the kernel and determines which should be employed.
System call list
Below is a list of those system calls that are common to most platforms.
In the list, the
Kernel
column indicates the kernel version
for those system calls that were new in Linux 2.2,
or have appeared since that kernel version.
Note the following points:
*
Where no kernel version is indicated,
the system call appeared in kernel 1.0 or earlier.
*
Where a system call is marked "1.2"
this means the system call probably appeared in a 1.1.x kernel version,
and first appeared in a stable kernel with 1.2.
(Development of the 1.2 kernel was initiated from a branch of kernel
1.0.6 via the 1.1.x unstable kernel series.)
*
Where a system call is marked "2.0"
this means the system call probably appeared in a 1.3.x kernel version,
and first appeared in a stable kernel with 2.0.
(Development of the 2.0 kernel was initiated from a branch of kernel
1.2.x, somewhere around 1.2.10,
via the 1.3.x unstable kernel series.)
*
Where a system call is marked "2.2"
this means the system call probably appeared in a 2.1.x kernel version,
and first appeared in a stable kernel with 2.2.0.
(Development of the 2.2 kernel was initiated from a branch of kernel
2.0.21 via the 2.1.x unstable kernel series.)
*
Where a system call is marked "2.4"
this means the system call probably appeared in a 2.3.x kernel version,
and first appeared in a stable kernel with 2.4.0.
(Development of the 2.4 kernel was initiated from a branch of
kernel 2.2.8 via the 2.3.x unstable kernel series.)
*
Where a system call is marked "2.6"
this means the system call probably appeared in a 2.5.x kernel version,
and first appeared in a stable kernel with 2.6.0.
(Development of kernel 2.6 was initiated from a branch
of kernel 2.4.15 via the 2.5.x unstable kernel series.)
*
Starting with kernel 2.6.0, the development model changed,
and new system calls may appear in each 2.6.x release.
In this case, the exact version number where the system call appeared
is shown.
*
In some cases, a system call was added to a stable kernel
series after it branched from the previous stable kernel
series, and then backported into the earlier stable kernel series.
For example some system calls that appeared in 2.6.x were also backported
into a 2.4.x release after 2.4.15.
When this is so, the version where the system call appeared
in both of the major kernel series is listed.
The list of system calls that are available as at kernel 2.6.25
(or in a few cases only on older kernels) is as follows:
On many platforms, including i386, socket calls are all multiplexed
(via glibc wrapper functions) through
socketcall(2)
and similarly System V IPC calls are multiplexed through
ipc(2).
The
getpmsg(2)
and
putpmsg(2)
calls are for kernels patched to support STREAMS,
and may never be in the standard kernel.
Roughly speaking, the code belonging to the system call
with number __NR_xxx defined in
/usr/include/asm/unistd.h
can be found in the kernel source in the routine
sys_xxx().
(The dispatch table for i386 can be found in
/usr/src/linux/arch/i386/kernel/entry.S.)
There are many exceptions, however, mostly because
older system calls were superseded by newer ones,
and this has been treated somewhat unsystematically.
On platforms with
proprietary OS emulation, such as parisc, sparc, sparc64 and alpha,
there are many additional system calls; mips64 also contains a full
set of 32-bit system calls.
Over time, changes to the interfaces of some system calls have been
necessary.
One reason for such changes was the need to increase the size of
structures or scalar values passed to the system call.
Because of these changes, there are now various groups
of related system calls
(e.g.,
truncate(2)
and
truncate64(2))
which perform similar tasks, but which vary in
details such as the size of their arguments.
(As noted earlier, applications are generally unaware of this:
the glibc wrapper functions do some work to ensure that the right
system call is invoked, and that ABI compatibility is
preserved for old binaries.)
Examples of systems calls that exist in multiple versions are
the following:
*
By now there are three different versions of
stat(2):
sys_stat()
(slot
__NR_oldstat),
sys_newstat()
(slot
__NR_stat),
and
sys_stat64()
(slot
__NR_stat64),
with the last being the most current.
A similar story applies for
lstat(2)
and
fstat(2).
*
Similarly, the defines
__NR_oldolduname,
__NR_olduname,
and
__NR_uname
refer to the routines
sys_olduname(),
sys_uname()
and
sys_newuname().
*
In Linux 2.0, a new version of
vm86(2)
appeared, with the old and the new kernel routines being named
sys_vm86old()
and
sys_vm86().
*
In Linux 2.4, a new version of
getrlimit(2)
appeared, with the old and the new kernel routines being named
sys_old_getrlimit()
(slot
__NR_getrlimit)
and
sys_getrlimit()
(slot
__NR_ugetrlimit).
*
Linux 2.4 increased the size of user and group IDs from 16 to 32 bits.
To support this change, a range of system calls were added
(e.g.,
chown32(2),
getuid32(2),
getgroups32(2),
setresuid32(2)),
superseding earlier calls of the same name without the
"32" suffix.
*
Linux 2.4 added support for applications on 32-bit architectures
to access large files (i.e., files for which the sizes and
file offsets can't be represented in 32 bits.)
To support this change, replacements were required for system calls
that deal with file offsets and sizes.
Thus the following system calls were added:
fcntl64(2),
ftruncate64(2),
getdents64(2),
stat64(2),
statfs64(2),
and their analogs that work with file descriptors or
symbolic links.
These system calls supersede the older system calls
which, except in the case of the "stat" calls,
have the same name without the "64" suffix.
On newer platforms that only have 64-bit file access and 32-bit uids
(e.g., alpha, ia64, s390x) there are no *64 or *32 calls.
Where the *64 and *32 calls exist, the other versions are obsolete.
*
The
rt_sig*
calls were added in kernel 2.2 to support the addition
of real-time signals (see
signal(7)).
These system calls supersede the older system calls of the same
name without the "rt_" prefix.
*
The
select(2)
and
mmap(2)
system calls use five or more arguments,
which caused problems the way
argument passing on the i386 used to be set up.
Thus, while other architectures have
sys_select()
and
sys_mmap()
corresponding to
__NR_select
and
__NR_mmap,
on i386 one finds
old_select()
and
old_mmap()
(routines that use a pointer to a
argument block) instead.
These days passing five arguments
is not a problem any more, and there is a
__NR__newselect
that corresponds directly to
sys_select()
and similarly
__NR_mmap2.
This page is part of release 3.14 of the Linux
man-pages
project.
A description of the project,
and information about reporting bugs,
can be found at
http://www.kernel.org/doc/man-pages/.
