syscalls - llamadas al sistema de Linux
Llamadas al sistema de Linux.
The system call is the fundamental interface between an
application and the Linux kernel.
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
chdir() which invokes the underlying "chdir" 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 on architectures without a
separate error register/flag, as noted in syscall(2); 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.
Below is a list of the Linux system calls. 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 Linux
1.0 or earlier.
- •
- Where a system call is marked "1.2" this means the system call
probably appeared in a Linux 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 Linux 1.3.x kernel version, and first appeared in a
stable kernel with Linux 2.0. (Development of the Linux 2.0 kernel was
initiated from a branch of Linux 1.2.x, somewhere around Linux 1.2.10, via
the Linux 1.3.x unstable kernel series.)
- •
- Where a system call is marked "2.2" this means the system call
probably appeared in a Linux 2.1.x kernel version, and first appeared in a
stable kernel with Linux 2.2.0. (Development of the Linux 2.2 kernel was
initiated from a branch of kernel Linux 2.0.21 via the Linux 2.1.x
unstable kernel series.)
- •
- Where a system call is marked "2.4" this means the system call
probably appeared in a Linux 2.3.x kernel version, and first appeared in a
stable kernel with Linux 2.4.0. (Development of the Linux 2.4 kernel was
initiated from a branch of Linux 2.2.8 via the Linux 2.3.x unstable kernel
series.)
- •
- Where a system call is marked "2.6" this means the system call
probably appeared in a Linux 2.5.x kernel version, and first appeared in a
stable kernel with Linux 2.6.0. (Development of Linux 2.6 was initiated
from a branch of Linux 2.4.15 via the Linux 2.5.x unstable kernel
series.)
- •
- Starting with Linux 2.6.0, the development model changed, and new system
calls may appear in each Linux 2.6.x release. In this case, the exact
version number where the system call appeared is shown. This convention
continues with the Linux 3.x kernel series, which followed on from Linux
2.6.39; and the Linux 4.x kernel series, which followed on from Linux
3.19; and the Linux 5.x kernel series, which followed on from Linux
4.20.
- •
- 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 Linux 2.6.x were also backported into a Linux 2.4.x release
after Linux 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 Linux 5.14 (or
in a few cases only on older kernels) is as follows:
On many platforms, including x86-32, socket calls are all
multiplexed (via glibc wrapper functions) through socketcall(2) and
similarly System V IPC calls are multiplexed through
ipc(2).
Although slots are reserved for them in the system call table, the
following system calls are not implemented in the standard kernel:
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), and vserver(2) (see also unimplemented(2)).
However, ftime(3), profil(3), and ulimit(3) exist as
library routines. The slot for phys(2) is in use since Linux 2.1.116
for umount(2); phys(2) will never be implemented. The
getpmsg(2) and putpmsg(2) calls are for kernels patched to
support STREAMS, and may never be in the standard kernel.
There was briefly set_zone_reclaim(2), added in Linux
2.6.13, and removed in Linux 2.6.16; this system call was never available to
user space.
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 Linux kernel source in the routine sys_xxx(). 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 operating-system emulation, such as 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, certain architectures (notably, longstanding 32-bit
architectures such as i386) now have 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),
getdents64(2), stat64(2), statfs64(2),
truncate64(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/GIDs
(e.g., alpha, ia64, s390x, x86-64), there is just a single version of the
UID/GID and file access system calls. On platforms (typically, 32-bit
platforms) where the *64 and *32 calls exist, the other versions are
obsolete.
- •
- The rt_sig* calls were added in Linux 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 in 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
an 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. s390x is
the only 64-bit architecture that has old_mmap().
- getxgid(2)
- returns a pair of GID and effective GID via registers r0 and
r20; it is provided instead of getgid(2) and
getegid(2).
- getxpid(2)
- returns a pair of PID and parent PID via registers r0 and
r20; it is provided instead of getpid(2) and
getppid(2).
- old_adjtimex(2)
- is a variant of adjtimex(2) that uses struct timeval32, for
compatibility with OSF/1.
- getxuid(2)
- returns a pair of GID and effective GID via registers r0 and
r20; it is provided instead of getuid(2) and
geteuid(2).
- sethae(2)
- is used for configuring the Host Address Extension register on low-cost
Alphas in order to access address space beyond first 27 bits.
La traducción al español de esta página del
manual fue creada por Juan José López Mellado
<laveneno@hotmail.com> y Juan Piernas <piernas@ditec.um.es>
Esta traducción es documentación libre; lea la
GNU General
Public License Version 3 o posterior con respecto a las condiciones de
copyright. No existe NINGUNA RESPONSABILIDAD.
Si encuentra algún error en la traducción de esta
página del manual, envíe un correo electrónico a
debian-l10n-spanish@lists.debian.org.