Editing System call

{{Short description|Way for programs to access kernel services}}
{{Distinguish|System command}}
{{Use dmy dates|date=March 2022}}
[[File:Linux kernel interfaces.svg|thumb|300px|A high-level overview of the Linux kernel's system call interface, which handles communication between its various components and the [[userspace]] ]]

In computing, a '''system call''' ('''syscall''') is the programmatic way in which a [[computer program]] requests a service from the [[operating system]]{{efn|In [[UNIX-like]] operating systems, system calls are used only for the [[Kernel (operating system)|kernel]] }} on which it is executed. This may include hardware-related services (for example, accessing a [[hard disk drive]] or accessing the device's camera), creation and execution of new [[process (computing)|processes]], and communication with integral [[kernel service]]s such as [[process scheduling]].  System calls provide an essential interface between a process and the operating system.

In most systems, system calls can only be made from [[userspace]] processes, while in some systems, [[OS/360 and successors]] for example, privileged system code also issues system calls.<ref>{{cite manual
 |     author = IBM
 |      title = IBM System/360 Operating System System Programmer's Guide
 |    section = Writing SVC Routines
 |    version = Third Edition
 |       date = March 1967
 |        url = http://bitsavers.org/pdf/ibm/360/os/R01-08/C28-6550-2_OSsysPrmg_Mar67.pdf
 |         id = C28-6550-2
 |      pages = 32–36
 }}</ref>

For [[embedded system]]s, system calls typically do not change the [[CPU modes|privilege mode]] of the CPU.

== Privileges ==
The [[Instruction set|architecture]] of most modern processors, with the exception of some embedded systems, involves a [[CPU modes|security model]]. For example, the ''[[ring (computer security)|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 [[Computer network|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 [[interrupt]]s. 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 library as an intermediary ==
Generally, systems provide a [[Library (computing)|library]] or [[API]] that sits between normal programs and the operating system.  On [[Unix-like]] systems, that API is usually part of an implementation of the [[C standard library|C library]] (libc), such as [[glibc]], that provides [[wrapper function]]s for the system calls, often named the same as the system calls they invoke. On [[Windows NT]], that API is part of the [[Native API]], in the {{mono|ntdll.dll}} library; this is an undocumented API used by implementations of the regular [[Windows API]] and directly used by some system programs on Windows.  The library's wrapper functions expose an ordinary function [[calling convention]] (a [[subroutine]] call on the [[assembly language|assembly]] level) for using the system call, as well as making the system call more [[modularity|modular]]. Here, the primary function of the wrapper is to place all the arguments to be passed to the system call in the appropriate [[processor register]]s (and maybe on the [[call stack]] as well), and also setting a unique system call number for the kernel to call. In this way the library, which exists between the OS and the application, increases [[Software portability|portability]].

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 architecture]]s (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, <code>fork</code> and <code>execve</code> are C library functions that in turn execute instructions that invoke the <code>fork</code> and <code>exec</code> 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 (programming language)|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 [[Application programming interface|API]], and provide [[Abstraction (computer science)|abstractions]] and [[Resource (computer science)|resource]] management.

IBM's [[OS/360 and successors|OS/360]], [[DOS/360 and successors|DOS/360]] and [[TSS/360]] implement most system calls through a library of assembly language [[Macro (computer science)|macros]],{{efn|In many but not all cases, IBM documented, e.g., the SVC number, the parameter registers.}} 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 programming language|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 [[VSE (operating system)|z/VSE]]. In more recent release of [[MVS/SP]] and in all later MVS versions, some system call macros generate Program Call (PC).

== Examples and tools ==
On [[Unix]], [[Unix-like]] and other [[POSIX]]-compliant operating systems, popular system calls are <code>[[open (system call)|open]]</code>, <code>[[read (system call)|read]]</code>, <code>[[write (system call)|write]]</code>, <code>[[close (system call)|close]]</code>, <code>[[wait (system call)|wait]]</code>, <code>[[exec (system call)|exec]]</code>, <code>[[fork (system call)|fork]]</code>, <code>[[exit (system call)|exit]]</code>, and <code>[[kill (system call)|kill]]</code>. Many modern operating systems have hundreds of system calls. For example, [[Linux kernel|Linux]] and [[OpenBSD]] each have over 300 different calls,<ref>{{cite web|url=http://man7.org/linux/man-pages/man2/syscalls.2.html|title=syscalls(2) - Linux manual page}}</ref><ref>{{cite web|url=http://bxr.su/OpenBSD/sys/kern/syscalls.c|website=BSD Cross Reference|author=OpenBSD|title=System call names (kern/syscalls.c)|date=2013-09-14}}</ref> [[NetBSD]] has close to 500,<ref>{{cite web|url=http://bxr.su/NetBSD/sys/kern/syscalls.c|website=BSD Cross Reference|author=NetBSD|title=System call names (kern/syscalls.c)|date=2013-10-17}}</ref> [[FreeBSD]] has over 500,<ref>{{cite web|url=http://fxr.watson.org/fxr/source/kern/syscalls.c|title=FreeBSD syscalls.c, the list of syscall names and IDs}}</ref> Windows has close to 2000, divided between win32k (graphical) and ntdll (core) system calls<ref>{{cite web|url=http://j00ru.vexillium.org/syscalls/win32k/32/|title=Windows WIN32K.SYS System Call Table (NT/2000/XP/2003/Vista/2008/7/8/10) |author=Mateusz "j00ru" Jurczyk | date=2017-11-05}}</ref> while [[Plan 9 from Bell Labs|Plan 9]] has 54.<ref>{{Cite web |title=sys.h |url=http://9p.io/sources/plan9/sys/src/libc/9syscall/sys.h |url-status=live |archive-url=https://web.archive.org/web/20230908211500/http://9p.io/sources/plan9/sys/src/libc/9syscall/sys.h |archive-date=Sep 8, 2023 |website=Plan 9 from Bell Labs |postscript=,}} the list of syscall names and IDs.</ref>

Tools such as [[strace]], [[ftrace]] and truss allow a process to execute from start and report all system calls the process invokes, or can attach to an already running process and intercept any system call made by the said process if the operation does not violate the permissions of the user. This special ability of the program is usually also implemented with system calls such as [[ptrace]] or system calls on files in [[procfs]].

== 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 (computing)|trap]]. Interrupts transfer control to the operating system [[Kernel (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 [[Complex instruction set computer|CISC]] architectures such as [[x86]] support additional techniques. For example, the x86 [[instruction set]] contains the instructions <code>SYSCALL</code>/<code>SYSRET</code> and <code>SYSENTER</code>/<code>SYSEXIT</code> (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.<ref>{{cite web|url=http://wiki.osdev.org/SYSENTER|title=SYSENTER |website=OSDev wiki |url-status=live |archive-url=https://web.archive.org/web/20231108202438/https://wiki.osdev.org/Sysenter |archive-date= Nov 8, 2023 }}</ref> [[Linux]] 2.5 began using this on the [[x86]], where available; formerly it used the <code>[[INT (x86 instruction)|INT]]</code> instruction, where the system call number was placed in the <code>EAX</code> [[processor register|register]] before [[INT (x86 instruction)|interrupt]] 0x80 was executed.<ref>{{cite web |url=http://kerneltrap.org/node/531 |title=Linux 2.5 gets vsyscalls, sysenter support |access-date=2008-01-01 |author=Anonymous |date=2002-12-19 |work=[[KernelTrap]]}}</ref><ref>{{cite web|url=http://articles.manugarg.com/systemcallinlinux2_6.html|title=Sysenter Based System Call Mechanism in Linux 2.6|date=2006|author=Manu Garg}}</ref>

An older mechanism is the [[call gate]]; originally used in [[Multics]] and later, for example, see [[call gate (Intel)|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<ref>{{cite web|url=http://x86.renejeschke.de/html/file_module_x86_id_26.html|title=Liberation: x86 Instruction Set Reference|work=renejeschke.de|access-date=4 July 2015}}</ref>) which uses [[x86 memory segmentation]] and the resulting lack of [[portability (software)|portability]] it causes, and the existence of the faster instructions mentioned above.

For [[IA-64]] architecture, <code>EPC</code> (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]] ({{mono|SVC}}), with the number in the instruction rather than in a register, implements a system call for legacy facilities in most of{{efn|The CP components of [[CP-67]] and [[VM (operating system)|VM]] use the Diagnose (DIAG) instruction as a Hypervisor CALL (HVC) from a virtual machine to CP.}} 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.
<!-- Does z/VSE use PC? -->

The [[PDP-11]] [[minicomputer]] used the {{mono|EMT}}, {{mono|TRAP}} and {{mono|IOT}} instructions, which, similar to the IBM System/360 {{mono|SVC}} and x86 {{mono|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 {{mono|CHMK}}, {{mono|CHME}}, and {{mono|CHMS}} instructions to make system calls to privileged code at various levels; the code is an argument to the instruction.

== Categories of system calls ==
System calls can be grouped roughly into six major categories:<ref>{{Cite book|title=Operating System Concepts|last=Silberschatz|first=Abraham|publisher=Wiley|others=Peter B Galvin; Greg Gagne|year=2018|isbn=9781119320913|edition=10th|location=Hoboken, NJ|pages=67|oclc=1004849022}}</ref>

:

# Process control
#* create process (for example, <code>[[fork (system call)|fork]]</code> on Unix-like systems, or <code>NtCreateProcess</code> in the [[Windows NT]] [[Native API]])
#* [[Kill (command)|terminate process]]
#* [[Loader (computing)|load]], [[exec (system call)|execute]]
#* get/set process attributes
#* [[Wait (system call)|wait]] for time, wait event, [[Signal (IPC)|signal]] event
#* [[Memory allocation|allocate]] and [[Garbage collection (computer science)|free]] memory
# File management
#* create file, delete file
#* open, close
#* read, write, reposition
#* get/set file attributes
# Device management
#* request device, release device
#* read, write, reposition
#* get/set device attributes
#* logically attach or detach devices
# 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.)
# Communication
#* create, delete communication connection
#* send, receive messages
#* transfer status information
#* attach or detach remote devices
# Protection
#* get/set file permissions

== Processor mode and context switching ==
System calls in most [[Unix-like]] systems are processed in [[kernel mode]], which is accomplished by changing the processor execution mode to a more privileged one, but no ''process'' [[context switch]] is necessary{{snd}} although a ''privilege'' context switch does occur. The hardware sees the world in terms of the execution mode according to the processor [[status register]], and processes are an abstraction provided by the operating system. A system call does not generally require a context switch to another process; instead, it is processed in the context of whichever process invoked it.<ref name="Bach1986pp15-16">Bach, Maurice J. (1986), ''The Design of the UNIX Operating System'', Prentice Hall, pp. 15–16.</ref><ref>{{cite web |url=http://www.progclub.org/pipermail/list/2011-October/000150.html |title=Discussion of system call implementation at ProgClub including quote from Bach 1986 |year=2011<!-- 1 October --> |first=John |last=Elliot |access-date=1 October 2011 |archive-date=24 July 2012 |archive-url=https://web.archive.org/web/20120724153438/https://www.progclub.org/pipermail/list/2011-October/000150.html |url-status=dead }}</ref>

In a [[Multithreading (computer architecture)|multithreaded]] process, system calls can be made from multiple [[Thread (computing)|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:<ref>{{cite web |url=http://www.cs.uic.edu/~jbell/CourseNotes/OperatingSystems/4_Threads.html |title=Threads}}</ref><ref>{{cite web |url=http://kevinmarquet.net/wp-content/uploads/threading.pdf |title=Threading Models}}</ref>

* ''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{{snd}} 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 distribution]]s, [[macOS]], [[iOS]], recent [[Microsoft Windows|Windows]] and [[Solaris (operating system)|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 (operating system)|Solaris]].

== See also ==
* [[DOS API]]
* [[Linux kernel API]]
* [[vDSO]]

== Notes ==
{{Notelist}}

== References ==
{{Reflist}}

== External links ==

* [http://fxr.watson.org/fxr/source/kern/syscalls.master A list of modern Unix-like system calls]
* {{usurped|1=[https://archive.today/20121220032539/http://www.makelinux.net/kernel_map/ Interactive Linux kernel map]}} with main API functions and structures, {{usurped|1=[https://web.archive.org/web/20180827040646/http://www.makelinux.net/kernel_map/LKM.pdf PDF]}} version
* [https://web.archive.org/web/20051024081539/http://docs.cs.up.ac.za/programming/asm/derick_tut/syscalls.html Linux system calls]{{snd}} system calls for [[Linux kernel]] 2.2, with [[IA-32]] [[calling convention]]s
* [http://www.tldp.org/LDP/khg/HyperNews/get/syscall/syscall86.html How System Calls Work on Linux/i86] (1996, based on the 1993 0.99.2 kernel)
* [http://articles.manugarg.com/systemcallinlinux2_6.html Sysenter Based System Call Mechanism in Linux 2.6] (2006)
* [https://www.ibm.com/developerworks/linux/library/l-system-calls ''Kernel command using Linux system calls''], IBM developerWorks
* Choudhary, Amit; [http://tldp.org/HOWTO/html_single/Implement-Sys-Call-Linux-2.6-i386 HOWTO for Implementing a System Call on Linux 2.6]
* Jorrit N. Herder, Herbert Bos, Ben Gras, Philip Homburg, and Andrew S. Tanenbaum, [https://www.usenix.org/publications/login/april-2006-volume-31-number-2/modular-system-programming-minix-3 Modular system programming on Minix 3], '';login:'' 31, no. 2 (April 2006); 19–28, accessed 5 March 2018
* [http://task3.cc/projects/bd-shell/ A simple open Unix Shell in C language]{{snd}} examples on System Calls under Unix
* [https://web.archive.org/web/20121224002314/http://netcode.cz/img/83/nativeapi.html Inside the Native API]{{snd}} [[Windows NT]] [[Native API]], including system calls
* Gulbrandsen, John; [http://www.codeguru.com/cpp/misc/misc/system/article.php/c8223/System-Call-Optimization-with-the-SYSENTER-Instruction.htm ''System Call Optimization with the SYSENTER Instruction''], CodeGuru.com, 8 October 2004
* [https://wiki.osdev.org/System_Calls osdev wiki]

{{Application binary interface}}

{{DEFAULTSORT:System Call}}
[[Category:Operating system technology]]
[[Category:Application programming interfaces]]
[[Category:System calls| ]]