System call
In computing, a system call (commonly abbreviated to syscall) is the programmatic way in which a
In most systems, system calls can only be made from
For embedded systems, system calls typically do not change the privilege mode of the CPU.
Privileges
The
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 library as an intermediary
Generally, systems provide a
The call to the library function itself does not cause a switch to
On
IBM's
Examples and tools
On
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
This is the only technique provided for many
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
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[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 in Service Request Block (SRB) mode.
The PDP-11 minicomputer used the EMT, TRAP 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.
Categories of system calls
System calls can be grouped roughly into six major categories:[12]
- Process control
- create process (for example, Native API)
- terminate process
- execute
- get/set process attributes
- signalevent
- allocate and freememory
- create process (for example,
- 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
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 Solarisversions.
- 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 Solaris.
See also
- Linux kernel API
- VDSO
Notes
References
- ^ IBM (March 1967). "Writing SVC Routines". IBM System/360 Operating System System Programmer's Guide (PDF). Third Edition. pp. 32–36. C28-6550-2.
- ^ "syscalls(2) - Linux manual page".
- ^ OpenBSD (14 September 2013). "System call names (kern/syscalls.c)". BSD Cross Reference.
- ^ NetBSD (17 October 2013). "System call names (kern/syscalls.c)". BSD Cross Reference.
- ^ "FreeBSD syscalls.c, the list of syscall names and IDs".
- ^ Mateusz "j00ru" Jurczyk (5 November 2017). "Windows WIN32K.SYS System Call Table (NT/2000/XP/2003/Vista/2008/7/8/10)".
{{cite web}}
: CS1 maint: numeric names: authors list (link) - ^ "sys.h". Plan 9 from Bell Labs. Archived from the original on 8 September 2023, the list of syscall names and IDs.
- ^ "SYSENTER". OSDev wiki. Archived from the original on 8 November 2023.
- ^ Anonymous (19 December 2002). "Linux 2.5 gets vsyscalls, sysenter support". KernelTrap. Retrieved 1 January 2008.
- ^ Manu Garg (2006). "Sysenter Based System Call Mechanism in Linux 2.6".
- ^ "Liberation: x86 Instruction Set Reference". renejeschke.de. Retrieved 4 July 2015.
- OCLC 1004849022.
- ^ Bach, Maurice J. (1986), The Design of the UNIX Operating System, Prentice Hall, pp. 15–16.
- ^ Elliot, John (2011). "Discussion of system call implementation at ProgClub including quote from Bach 1986".
- ^ "Threads".
- ^ "Threading Models" (PDF).
External links
- A list of modern Unix-like system calls
- Interactive Linux kernel map with main API functions and structures, PDF version
- Linux system calls – system calls for Linux kernel 2.2, with IA-32 calling conventions
- How System Calls Work on Linux/i86 (1996, based on the 1993 0.99.2 kernel)
- Sysenter Based System Call Mechanism in Linux 2.6 (2006)
- Kernel command using Linux system calls, IBM developerWorks
- Choudhary, Amit; HOWTO for Implementing a System Call on Linux 2.6
- Jorrit N. Herder, Herbert Bos, Ben Gras, Philip Homburg, and Andrew S. Tanenbaum, Modular system programming on Minix 3, ;login: 31, no. 2 (April 2006); 19–28, accessed 5 March 2018
- A simple open Unix Shell in C language – examples on System Calls under Unix
- Inside the Native API – Native API, including system calls
- Gulbrandsen, John; System Call Optimization with the SYSENTER Instruction, CodeGuru.com, 8 October 2004