العربية
中国
Français
Deutsch
Ελληνική
हिन्दी
Italiano
日本語
Português
Русский
EspañolSYSTEM CALL
In computing, a 'system call' is the mechanism used by an application program to request service from the operating system.
In addition to processing data in its own memory space, an application program might want to use data and services provided by the system. Examples of the system providing a service to an application include: reporting the current time, allocating memory space, reading from or writing to a file, printing text on screen, and a host of other necessary actions.
Since the machine and its devices are shared between all the programs, the access must be synchronized. Some of the activities may fail the system or even destroy something physically. For these reasons, the access to the physical environment is strictly managed by the BIOS and operating system. The code and data of the OS is located in a protected area of memory and cannot be accessed/damaged by user applications. The only gate to the hardware is system calls, which are defined in the operating system. These calls check the requests and deliver them to the OS drivers, which control the hardware input/output directly.
Modern processors can typically execute instructions in several, very different, privileged states. In systems with two levels, they are usually called user mode and supervisor mode. Different privilege levels are provided so that operating systems can restrict the operations that programs running under them can perform, for reasons of security and stability. Such operations include accessing hardware devices, enabling and disabling interrupts, changing privileged processor state, and accessing memory management units.
With the development of separate operating modes with varying levels of privilege, a mechanism was needed for transferring control safely from lesser privileged modes to higher privileged modes. Less privileged code could not simply transfer control to more privileged code at any arbitrary point and with any arbitrary processor state. To allow it to do so could allow it to break security. For instance, the less privileged code could cause the higher privileged code to execute in the wrong order, or provide it with a bad stack.
System calls often use a special CPU instruction which causes the processor to transfer control to more privileged code, as previously specified by the more privileged code. This allows the more privileged code to specify where it will be entered as well as important processor state at the time of entry.
When the system call is invoked, the program which invoked it is interrupted, and information needed to continue its execution later is saved. The processor then begins executing the higher privileged code, which, by examining processor state set by the less privileged code and/or its stack, determines what is being requested. When it is finished, it returns to the program, restoring the saved state, and the program continues executing.
Note that in many cases, the actual return to the program may not be immediate. If the system call performs any kind of lengthy I/O operation, for instance disk or network access, the program may be suspended (“blocked”) and taken off the “ready” queue until the operation is complete, at which point the operating system will again make it a candidate for execution.
Generally, operating systems provide a library that sits between normal programs and the rest of the operating system, usually the C library (libc), such as glibc and the Microsoft C runtime. This library handles the low-level details of passing information to the kernel and switching to supervisor mode, as well as any data processing and preparation which does not need to be done in privileged mode. Ideally, this reduces the coupling between the operating system and the application, and increases portability.
On exokernel based systems, the library is especially important as an intermediary. On exokernels, OSes shield user applications from the very low level kernel API, and provide abstractions and resource management.
On POSIX and similar systems, popular system calls are open, read, write, close, wait, exec, fork, exit, and kill. Many of today's operating systems have hundreds of system calls. For example, Linux has 319 different system calls. FreeBSD has about the same (almost 330).
Tools such as strace and truss report the system calls made by a running process.
In the Java platform, there is no need for the Java virtual machine to interrupt itself to make the system call safer. The effect is reached by providing a higher level of isolation by renunciation of arbitrary memory pointers, which allows the safe placement of all the code into one memory space. The Java virtual machine is indistinguishable from its supporting library Java Runtime Environment in this platform where API consists of a set of system objects, invoking methods of which system calls are made, and no privileged instructions are needed. A similar approach is used by Microsoft in its .Net platform and Singularity OS.
Implementing system calls requires a control transfer 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 kernel so software simply needs to set up some register with the system call number they want and execute the software interrupt. Linux uses this implementation on x86 where the system call number is placed in the EAX register before interrupt 0x80 is executed.
For many RISC processors this is the only feasible implementation, but CISC architectures such as x86 support additional techniques. One example is SYSCALL/SYSRET which is very similar to SYSENTER/SYSEXIT (the two mechanisms were created by Intel and AMD independently, but do basically 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.
An older x86 mechanism is called a call gate and is a way for a program to literally call a kernel function directly using a safe control transfer mechanism the kernel sets up in advance. This approach has been unpopular, presumably due to the requirement of a far call which uses x86 segmentation and the resulting lack of portability it causes, and existence of the faster instructions mentioned above.
★ Linux system calls - system calls for Linux kernel 2.2, with IA32 calling conventions
★ How System Calls Work on Linux/i86
★ Sysenter Based System Call Mechanism in Linux 2.6
| Contents |
| Background |
| Mechanism |
| The library as an intermediary |
| Examples and tools |
| Typical implementations |
| External links |
Background
In addition to processing data in its own memory space, an application program might want to use data and services provided by the system. Examples of the system providing a service to an application include: reporting the current time, allocating memory space, reading from or writing to a file, printing text on screen, and a host of other necessary actions.
Since the machine and its devices are shared between all the programs, the access must be synchronized. Some of the activities may fail the system or even destroy something physically. For these reasons, the access to the physical environment is strictly managed by the BIOS and operating system. The code and data of the OS is located in a protected area of memory and cannot be accessed/damaged by user applications. The only gate to the hardware is system calls, which are defined in the operating system. These calls check the requests and deliver them to the OS drivers, which control the hardware input/output directly.
Modern processors can typically execute instructions in several, very different, privileged states. In systems with two levels, they are usually called user mode and supervisor mode. Different privilege levels are provided so that operating systems can restrict the operations that programs running under them can perform, for reasons of security and stability. Such operations include accessing hardware devices, enabling and disabling interrupts, changing privileged processor state, and accessing memory management units.
With the development of separate operating modes with varying levels of privilege, a mechanism was needed for transferring control safely from lesser privileged modes to higher privileged modes. Less privileged code could not simply transfer control to more privileged code at any arbitrary point and with any arbitrary processor state. To allow it to do so could allow it to break security. For instance, the less privileged code could cause the higher privileged code to execute in the wrong order, or provide it with a bad stack.
Mechanism
System calls often use a special CPU instruction which causes the processor to transfer control to more privileged code, as previously specified by the more privileged code. This allows the more privileged code to specify where it will be entered as well as important processor state at the time of entry.
When the system call is invoked, the program which invoked it is interrupted, and information needed to continue its execution later is saved. The processor then begins executing the higher privileged code, which, by examining processor state set by the less privileged code and/or its stack, determines what is being requested. When it is finished, it returns to the program, restoring the saved state, and the program continues executing.
Note that in many cases, the actual return to the program may not be immediate. If the system call performs any kind of lengthy I/O operation, for instance disk or network access, the program may be suspended (“blocked”) and taken off the “ready” queue until the operation is complete, at which point the operating system will again make it a candidate for execution.
The library as an intermediary
Generally, operating systems provide a library that sits between normal programs and the rest of the operating system, usually the C library (libc), such as glibc and the Microsoft C runtime. This library handles the low-level details of passing information to the kernel and switching to supervisor mode, as well as any data processing and preparation which does not need to be done in privileged mode. Ideally, this reduces the coupling between the operating system and the application, and increases portability.
On exokernel based systems, the library is especially important as an intermediary. On exokernels, OSes shield user applications from the very low level kernel API, and provide abstractions and resource management.
Examples and tools
On POSIX and similar systems, popular system calls are open, read, write, close, wait, exec, fork, exit, and kill. Many of today's operating systems have hundreds of system calls. For example, Linux has 319 different system calls. FreeBSD has about the same (almost 330).
Tools such as strace and truss report the system calls made by a running process.
In the Java platform, there is no need for the Java virtual machine to interrupt itself to make the system call safer. The effect is reached by providing a higher level of isolation by renunciation of arbitrary memory pointers, which allows the safe placement of all the code into one memory space. The Java virtual machine is indistinguishable from its supporting library Java Runtime Environment in this platform where API consists of a set of system objects, invoking methods of which system calls are made, and no privileged instructions are needed. A similar approach is used by Microsoft in its .Net platform and Singularity OS.
Typical implementations
Implementing system calls requires a control transfer 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 kernel so software simply needs to set up some register with the system call number they want and execute the software interrupt. Linux uses this implementation on x86 where the system call number is placed in the EAX register before interrupt 0x80 is executed.
For many RISC processors this is the only feasible implementation, but CISC architectures such as x86 support additional techniques. One example is SYSCALL/SYSRET which is very similar to SYSENTER/SYSEXIT (the two mechanisms were created by Intel and AMD independently, but do basically 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.
An older x86 mechanism is called a call gate and is a way for a program to literally call a kernel function directly using a safe control transfer mechanism the kernel sets up in advance. This approach has been unpopular, presumably due to the requirement of a far call which uses x86 segmentation and the resulting lack of portability it causes, and existence of the faster instructions mentioned above.
External links
★ Linux system calls - system calls for Linux kernel 2.2, with IA32 calling conventions
★ How System Calls Work on Linux/i86
★ Sysenter Based System Call Mechanism in Linux 2.6
This article provided by Wikipedia. To edit the contents of this article, click here for original source.
psst.. try this: add to faves
