Professional Documents
Culture Documents
System Call: Syscall) Is The Programmatic Way in Which A Computer
System Call: Syscall) Is The Programmatic Way in Which A Computer
Contents
Privileges
The library as an intermediary
Examples and tools
Typical implementations
Categories of system calls
Processor mode and context switching
See also
Notes
References
External links
Privileges
The architecture of most modern processors, with the exception of some embedded systems, involves a
security model. For example, the rings model specifies multiple privilege levels under which software may
be executed: a program is usually limited to its own address space so that it cannot access or modify other
running programs or the operating system itself, and is usually prevented from directly manipulating
hardware devices (e.g. the frame buffer or network devices).
However, many applications need access to these components, so system calls are made available by the
operating system to provide well-defined, safe implementations for such operations. The operating system
executes at the highest level of privilege, and allows applications to request services via system calls, which
are often initiated via interrupts. An interrupt automatically puts the CPU into some elevated privilege level
and then passes control to the kernel, which determines whether the calling program should be granted the
requested service. If the service is granted, the kernel executes a specific set of instructions over which the
calling program has no direct control, returns the privilege level to that of the calling program, and then
returns control to the calling program.
The call to the library function itself does not cause a switch to kernel mode and is usually a normal
subroutine call (using, for example, a "CALL" assembly instruction in some Instruction set architectures
(ISAs)). The actual system call does transfer control to the kernel (and is more implementation-dependent
and platform-dependent than the library call abstracting it). For example, in Unix-like systems, fork and
execve are C library functions that in turn execute instructions that invoke the fork and exec system
calls. Making the system call directly in the application code is more complicated and may require
embedded assembly code to be used (in C and C++), as well as requiring knowledge of the low-level
binary interface for the system call operation, which may be subject to change over time and thus not be
part of the application binary interface; the library functions are meant to abstract this away.
On exokernel based systems, the library is especially important as an intermediary. On exokernels, libraries
shield user applications from the very low level kernel API, and provide abstractions and resource
management.
IBM's OS/360 and DOS/360 implement most system calls through a library of assembly language
macros,[a] although there are a few services with a call linkage. This reflects their origin at a time when
programming in assembly language was more common than high-level language usage. IBM system calls
were therefore not directly executable by high-level language programs, but required a callable assembly
language wrapper subroutine. Since then, IBM has added many services that can be called from high level
languages in, e.g., z/OS and z/VSE.
Typical implementations
Implementing system calls requires a transfer of control from user space to kernel space, which involves
some sort of architecture-specific feature. A typical way to implement this is to use a software interrupt or
trap. Interrupts transfer control to the operating system kernel, so software simply needs to set up some
register with the system call number needed, and execute the software interrupt.
This is the only technique provided for many RISC processors, but CISC architectures such as x86 support
additional techniques. For example, the x86 instruction set contains the instructions SYSCALL/SYSRET
and SYSENTER/SYSEXIT (these two mechanisms were independently created by AMD and Intel,
respectively, but in essence they do the same thing). These are "fast" control transfer instructions that are
designed to quickly transfer control to the kernel for a system call without the overhead of an interrupt.[8]
Linux 2.5 began using this on the x86, where available; formerly it used the INT instruction, where the
system call number was placed in the EAX register before interrupt 0x80 was executed.[9][10]
An older mechanism is the call gate; originally used in Multics and later, for example, see call gate on the
Intel x86. It allows a program to call a kernel function directly using a safe control transfer mechanism,
which the operating system sets up in advance. This approach has been unpopular on x86, presumably due
to the requirement of a far call (a call to a procedure located in a different segment than the current code
segment[11]) which uses x86 memory segmentation and the resulting lack of portability it causes, and the
existence of the faster instructions mentioned above.
For IA-64 architecture, EPC (Enter Privileged Code) instruction is used. The first eight system call
arguments are passed in registers, and the rest are passed on the stack.
In the IBM System/360 mainframe family, and its successors, a Supervisor Call instruction (SVC), with the
number in the instruction rather than in a register, implements a system call for legacy facilities in most of[b]
IBM's own operating systems, and for all system calls in Linux. In later versions of MVS, IBM uses the
Program Call (PC) instruction for many newer facilities. In particular, PC is used when the caller might be
in Service Request Block (SRB) mode.
The PDP-11 minicomputer used the EMT and IOT instructions, which, similar to the IBM System/360
SVC and x86 INT, put the code in the instruction; they generate interrupts to specific addresses,
transferring control to the operating system. The VAX 32-bit successor to the PDP-11 series used the
CHMK, CHME, and CHMS instructions to make system calls to privileged code at various levels; the code is
an argument to the instruction.
1. Process control
create process (for example, fork on Unix-like systems, or NtCreateProcess in the
Windows NT Native API)
terminate process
load, execute
get/set process attributes
wait for time, wait event, signal event
allocate and free memory
2. File management
create file, delete file
open, close
read, write, reposition
get/set file attributes
3. Device management
request device, release device
read, write, reposition
get/set device attributes
logically attach or detach devices
4. Information maintenance
get/set total system information (including time, date, computer name, enterprise etc.)
get/set process, file, or device metadata (including author, opener, creation time and
date, etc.)
5. Communication
create, delete communication connection
send, receive messages
transfer status information
attach or detach remote devices
6. Protection
get/set file permissions
In a multithreaded process, system calls can be made from multiple threads. The handling of such calls is
dependent on the design of the specific operating system kernel and the application runtime environment.
The following list shows typical models followed by operating systems:[15][16]
Many-to-one model: All system calls from any user thread in a process are handled by a
single kernel-level thread. This model has a serious drawback – any blocking system call
(like awaiting input from the user) can freeze all the other threads. Also, since only one
thread can access the kernel at a time, this model cannot utilize multiple cores of
processors.
One-to-one model: Every user thread gets attached to a distinct kernel-level thread during a
system call. This model solves the above problem of blocking system calls. It is found in all
major Linux distributions, macOS, iOS, recent Windows and Solaris versions.
Many-to-many model: In this model, a pool of user threads is mapped to a pool of kernel
threads. All system calls from a user thread pool are handled by the threads in their
corresponding kernel thread pool.
Hybrid model: This model implements both many to many and one to one models
depending upon the choice made by the kernel. This is found in old versions of IRIX, HP-UX
and Solaris.
See also
Linux kernel API
VDSO
Notes
a. In many but not all cases, IBM documented, e.g., the SVC number, the parameter registers.
b. The CP components of CP-67 and VM use the Diagnose (DIAG) instruction as a Hypervisor
CALL (HVC) from a virtual machine to CP.
References
1. IBM (March 1967). "Writing SVC Routines". IBM System/360 Operating System System
Programmer's Guide (http://bitsavers.org/pdf/ibm/360/os/R01-08/C28-6550-2_OSsysPrmg_
Mar67.pdf) (PDF). Third Edition. pp. 32–36. C28-6550-2.
2. "syscalls(2) - Linux manual page" (http://man7.org/linux/man-pages/man2/syscalls.2.html).
3. OpenBSD (14 September 2013). "System call names (kern/syscalls.c)" (http://bxr.su/OpenB
SD/sys/kern/syscalls.c). BSD Cross Reference.
4. NetBSD (17 October 2013). "System call names (kern/syscalls.c)" (http://bxr.su/NetBSD/sys/
kern/syscalls.c). BSD Cross Reference.
5. "FreeBSD syscalls.c, the list of syscall names and IDs" (http://fxr.watson.org/fxr/source/kern/
syscalls.c).
6. Author: Mateusz "j00ru" Jurczyk (5 November 2017). "Windows WIN32K.SYS System Call
Table (NT/2000/XP/2003/Vista/2008/7/8/10)" (http://j00ru.vexillium.org/syscalls/win32k/32/).
{{cite web}}: |author= has generic name (help)
7. "Plan 9 sys.h, the list of syscall names and IDs" (http://9p.io/sources/plan9/sys/src/libc/9sysc
all/sys.h).
8. "SYSENTER (OSDev wiki)" (http://wiki.osdev.org/SYSENTER).
9. Anonymous (19 December 2002). "Linux 2.5 gets vsyscalls, sysenter support" (http://kerneltr
ap.org/node/531). KernelTrap. Retrieved 1 January 2008.
10. Manu Garg (2006). "Sysenter Based System Call Mechanism in Linux 2.6" (http://articles.ma
nugarg.com/systemcallinlinux2_6.html).
11. "Liberation: x86 Instruction Set Reference" (http://x86.renejeschke.de/html/file_module_x86_
id_26.html). renejeschke.de. Retrieved 4 July 2015.
12. Silberschatz, Abraham (2018). Operating System Concepts. Peter B Galvin; Greg Gagne
(10th ed.). Hoboken, NJ: Wiley. p. 67. ISBN 9781119320913. OCLC 1004849022 (https://ww
w.worldcat.org/oclc/1004849022).
13. Bach, Maurice J. (1986), The Design of the UNIX Operating System, Prentice Hall, pp. 15–
16.
14. Elliot, John (2011). "Discussion of system call implementation at ProgClub including quote
from Bach 1986" (http://www.progclub.org/pipermail/list/2011-October/000150.html).
15. "Threads" (http://www.cs.uic.edu/~jbell/CourseNotes/OperatingSystems/4_Threads.html).
16. "Threading Models" (http://kevinmarquet.net/wp-content/uploads/threading.pdf) (PDF).
External links
Linux 64-bit system call reference/listing (http://www.cpu2.net/linuxabi.html) Up to kernel
version 4.20
Linux system call reference (https://syscalls.kernelgrok.com/) Updated system call reference
for Linux kernel 2.6.35.4, includes register and data structure references. Also for Linux
kernel 4.14 64 bit (https://syscalls64.paolostivanin.com) and 32 bit (https://syscalls32.paolost
ivanin.com).
A list of modern Unix-like system calls (http://fxr.watson.org/fxr/source/kern/syscalls.master)
Interactive Linux kernel map (https://www.makelinux.net/kernel_map/) with main API
functions and structures, PDF (https://www.makelinux.net/kernel_map/LKM.pdf) version
Linux system calls (https://web.archive.org/web/20051024081539/http://docs.cs.up.ac.za/pro
gramming/asm/derick_tut/syscalls.html) – system calls for Linux kernel 2.2, with IA-32 calling
conventions
How System Calls Work on Linux/i86 (http://www.tldp.org/LDP/khg/HyperNews/get/syscall/s
yscall86.html) (1996, based on the 1993 0.99.2 kernel)
Sysenter Based System Call Mechanism in Linux 2.6 (http://articles.manugarg.com/systemc
allinlinux2_6.html) (2006)
Kernel command using Linux system calls (http://www.ibm.com/developerworks/linux/library/
l-system-calls), IBM developerWorks
Choudhary, Amit; HOWTO for Implementing a System Call on Linux 2.6 (http://tldp.org/HOW
TO/html_single/Implement-Sys-Call-Linux-2.6-i386)
Jorrit N. Herder, Herbert Bos, Ben Gras, Philip Homburg, and Andrew S. Tanenbaum,
Modular system programming on Minix 3 (https://www.usenix.org/publications/login/april-200
6-volume-31-number-2/modular-system-programming-minix-3), ;login: 31, no. 2 (April 2006);
19–28, accessed 5 March 2018
A simple open Unix Shell in C language (http://task3.cc/projects/bd-shell/) – examples on
System Calls under Unix
Inside the Native API (https://web.archive.org/web/20121224002314/http://netcode.cz/img/8
3/nativeapi.html) – Windows NT Native API, including system calls
Gulbrandsen, John; System Call Optimization with the SYSENTER Instruction (http://www.c
odeguru.com/cpp/misc/misc/system/article.php/c8223/System-Call-Optimization-with-the-SY
SENTER-Instruction.htm), CodeGuru.com, 8 October 2004