In computing, asystem call (commonly abbreviated tosyscall) is the programmatic way in which acomputer program requests a service from theoperating system[a] on which it is executed. This may include hardware-related services (for example, accessing ahard disk drive or accessing the device's camera), creation and execution of newprocesses, and communication with integralkernel services such asprocess scheduling. System calls provide an essential interface between a process and the operating system.
In most systems, system calls can only be made fromuserspace processes, while in some systems,OS/360 and successors for example, privileged system code also issues system calls.[1]
Forembedded systems, system calls typically do not change theprivilege mode of the CPU.
Thearchitecture of most modern processors, with the exception of some embedded systems, involves asecurity model. For example, therings model specifies multiple privilege levels under which software may be executed: a program is usually limited to its ownaddress 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. theframe buffer ornetwork 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 viainterrupts. 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.
Generally, systems provide alibrary orAPI that sits between normal programs and the operating system. OnUnix-like systems, that API is usually part of an implementation of theC library (libc), such asglibc, that provideswrapper functions for the system calls, often named the same as the system calls they invoke. OnWindows NT, that API is part of theNative API, in thentdll.dll library; this is an undocumented API used by implementations of the regularWindows API and directly used by some system programs on Windows. The library's wrapper functions expose an ordinary functioncalling convention (asubroutine call on theassembly level) for using the system call, as well as making the system call moremodular. Here, the primary function of the wrapper is to place all the arguments to be passed to the system call in the appropriateprocessor registers (and maybe on thecall 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, increasesportability.
The call to the library function itself does not cause a switch tokernel mode and is usually a normalsubroutine call (using, for example, a "CALL" assembly instruction in someInstruction 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, inUnix-like systems,fork andexecve are C library functions that in turn execute instructions that invoke thefork andexec system calls. Making the system call directly in theapplication code is more complicated and may require embedded assembly code to be used (inC andC++), 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 theapplication binary interface; the library functions are meant to abstract this away.
Onexokernel based systems, the library is especially important as an intermediary. On exokernels, libraries shield user applications from the very low level kernelAPI, and provideabstractions andresource management.
IBM'sOS/360,DOS/360 andTSS/360 implement most system calls through a library of assembly languagemacros,[b] 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 thanhigh-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 andz/VSE. In more recent release ofMVS/SP and in all later MVS versions, some system call macros generate Program Call (PC).
OnUnix,Unix-like and otherPOSIX-compliant operating systems, popular system calls areopen,read,write,close,wait,exec,fork,exit, andkill. Many modern operating systems have hundreds of system calls. For example,Linux andOpenBSD each have over 300 different calls,[2][3]NetBSD has close to 500,[4]FreeBSD has over 500,[5] Windows has close to 2000, divided between win32k (graphical) and ntdll (core) system calls[6] whilePlan 9 has 54.[7]
Tools such asstrace,ftrace andtruss 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 asptrace or system calls on files inprocfs.
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 asoftware interrupt ortrap. Interrupts transfer control to the operating systemkernel, 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 manyRISC processors, butCISC architectures such asx86 support additional techniques. For example, the x86instruction set contains the instructionsSYSCALL/SYSRET andSYSENTER/SYSEXIT (these two mechanisms were independently created byAMD andIntel, 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 thex86, where available; formerly it used theINT instruction, where the system call number was placed in theEAXregister beforeinterrupt 0x80 was executed.[9][10]
An older mechanism is thecall gate; originally used inMultics and later, for example, seecall gate on the Intelx86. 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 usesx86 memory segmentation and the resulting lack ofportability it causes, and the existence of the faster instructions mentioned above.
ForIA-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 theIBM System/360 mainframe family, and its successors, aSupervisor Call instruction (SVC), with the number in the instruction rather than in a register, implements a system call for legacy facilities in most of[c] 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 inService Request Block (SRB) mode.
ThePDP-11minicomputer used theEMT,TRAP andIOT instructions, which, similar to the IBM System/360SVC and x86INT, put the code in the instruction; they generate interrupts to specific addresses, transferring control to the operating system. TheVAX 32-bit successor to the PDP-11 series used theCHMK,CHME, andCHMS instructions to make system calls to privileged code at various levels; the code is an argument to the instruction.
System calls can be grouped roughly into six major categories:[12]
fork on Unix-like systems, orNtCreateProcess in theWindows NTNative API)System calls in mostUnix-like systems are processed inkernel mode, which is accomplished by changing the processor execution mode to a more privileged one, but noprocesscontext switch is necessary – although aprivilege context switch does occur. The hardware sees the world in terms of the execution mode according to the processorstatus 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.[13][14]
In amultithreaded process, system calls can be made from multiplethreads. 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]
{{cite web}}: CS1 maint: numeric names: authors list (link)