The purpose of the system call is to request system services. The operating system does not allow users to directly operate various hardware resources, so user programs can only request the kernel for its services through system calls and use various resources indirectly.

#The functions provided by the operating system are usually not implemented by the application itself. For example, to operate on files, the application must make system calls, because only the operating system has the authority to directly manage peripheral devices. Another example is the synchronous mutual exclusion operation between processes or threads, which must also be completed by the operating system to maintain kernel variables.

Look at a complete computer system from bottom to top: physical hardware->OS kernel->OS service->application. The OS kernel here plays a key role in "connecting the previous to the next", managing physical hardware downwards and providing interfaces for operating system services and applications upwards. The interface here is the system call.

The application process usually runs in user mode. When it calls a system call, the process enters kernel mode and executes the code inside the kernel, thus having the authority to execute privileged instructions and complete specific functions. . In other words, system calls are the entrance for applications to actively enter the operating system kernel.

1. The difference between system calls and library functions

Library functions

As the name suggests, functions are placed in the library. It is to compile some commonly used functions and put them into a file for others to use. When others use it, just add the file name to it using #include, usually in the lib file.

Library functions are mainly provided by two parties: one is provided by the operating system; the other is provided by a third party.

• These functions provided by the system encapsulate or combine system calls to achieve more functions. Such library functions can implement some operations that are more complex for the kernel. For example, the read function can directly read files based on parameters, but the hidden files behind it, such as which track, which sector, and which memory are loaded into it, are issues that programmers do not need to care about. These operations also include system calls. For example, the write() system function will call the system call of the same name to complete the writing operation.

• For third-party libraries, they are actually the same as system libraries, except that they are less likely to directly use system calls, but are implemented through the API interface provided by the system. For example, printf actually calls the write() system function. Most of the third-party library functions are encapsulation of system functions.

The connection between system calls and library functions:

In fact, what the system calls provide to users is directly As for pure advanced services, if we want to be more user-friendly and have functions that are more suitable for specific situations, then we need to be defined by the users themselves, so library functions are derived, which wrap some system calls. For example, when we want to print a sentence in C language, if the library function printf is not used, then we need to implement it ourselves and call some system functions such as putc() and write(). It seems more troublesome, so system calls are for the convenience of using the operating system interface, while library functions are for the convenience of people's programming.

For example, under the Linux operating system, the C language library function printf actually uses the write system call; while the library function strcpy (string copy) does not use any system call. In addition, the system call interface of a system is usually the smallest set that can complete all necessary functions. There may be multiple library functions that encapsulate the same system call. For example, in Linux, the three library functions malloc, calloc and free are all completed by calling the brk system call.

The relationship between application programs, library functions and system calls is shown in the figure below:

The difference between system calls and library functions:

Library function calls are part of the language or application, while system calls are part of the operating system.

System call is the interface for the application to interact with the kernel. In long-term programming, people have discovered that using system functions has a major disadvantage, which is the portability of the program. For example, the system call functions provided by Linux are different from those of Windows.

Library function calls are oriented to application development, which is equivalent to the API of the application. There are many reasons for using this method:

• Double buffering technology; (Library functions and system calls Two-layer buffering, reducing the number of system calls)
• Portability (encapsulating system functions of different operating systems, with consistent external interfaces)
• Some defects in the underlying call itself;
• Let the API also have levels and specialized work orientations;

2. CPU kernel mode and user mode

Usually, the processor has two modes: "user mode" and "kernel mode". A tag bit is used to identify which mode it is currently in. Kernel mode can run all instructions, including privileged instructions (mainly some hardware management instructions, such as instructions that modify the contents of the base address register), while user mode cannot execute privileged instructions. This design is mainly for security issues, that is, the operating system is responsible for managing the hardware to avoid hardware problems caused by incorrect design of upper-layer applications.

Since only the operating system can directly operate the hardware, the operating system must provide interfaces to provide applications with access to hardware functions. These interfaces are called system calls.

When the operating system receives a system call request, it will cause the processor to enter kernel mode to perform instructions such as I/O operations and modify the contents of the base address register. After processing the system call content, the operation The system will return the processor to user mode to execute user code.

Corresponds to the kernel mode and user mode of the CPU. The running state of the process is divided into tube state (core state) and eye state (user state). For details, please see the article: Operating system - user mode and core mode

4. The connection between system calls and interrupts

Interrupt (Interrupt) It usually means that a pending event occurs inside or outside the CPU, so the CPU must change the execution order of the current instructions to handle such events. Before introducing the relationship between interrupts and system calls, let’s first classify interrupts.

Interrupts can be roughly divided into two categories:

• Asynchronous interrupts (external interrupts) : generated by other hardware outside the CPU, say this Class interrupts are asynchronous, which means that the interrupt signal can be emitted at any time and has nothing to do with the clock beat of the CPU itself. Such as clock interruption, hard disk read and write service request interruption, etc.

• Synchronous interrupts (internal interrupt/exception): generated inside the CPU, it is said that this type of interrupt is synchronous, which means that the transmission time of the interrupt signal must be at the current time After the instruction execution is completed. Generally, they come from internal events of the CPU or events during program execution, such as illegal opcodes, address out-of-bounds, floating point overflow, etc.

Synchronous interrupts (exceptions) are divided into the following categories:

• Processor-detected exceptions: The processor is Interrupts detected while executing instructions, such as a divide-by-zero operation.

• Faults: An abnormal condition occurs, but after the abnormal condition is eliminated, the original program flow can continue to execute without any impact, such as page faults abnormal. Note that the instruction that triggered the interrupt will be re-executed.

• Traps: Interrupts caused by trapped instructions, usually used for program debugging.

• Aborts: An important error occurs inside the CPU, such as a hardware error or an error in the system table value. Once this interruption occurs, the error is unrecoverable and the current process can only be terminated.

• Programmed exceptions: Also known as software interrupts (soft interrupts), interrupts actively initiated by the programmer's code, used to implement System calls. For example, in Linux, the int 0x80 instruction is used to implement system calls.

So far, we have discovered the relationship between interrupts and system calls: System calls are a special type of interrupt (soft interrupt).

5. Kernel processing of system calls

In x86 machines, an 8-bit number (0~255) is used to distinguish For various interrupts, this number is called an interrupt vector. One of the interrupt vectors, 128 (0x80), is specifically used to execute system calls.

In the Linux system, there is a system table called Interrupt DescriptorTable, referred to as IDT. There are 256 entries in the IDT table, which stores the mapping relationship from interrupt vectors to corresponding processing routines (interrupt or exceptionhandler). When an interrupt occurs, the CPU finds the address of the corresponding processing routine from the IDT table and executes it.

The system call processing routine occupies an entry in the IDT table. This item is initialized in the trap_init function, as follows: set_system_gate(SYSCALL_VECTOR,&system_call);. As mentioned before, the value of SYSCALL_VECTOR in the above code is 128.

When a system call occurs, the system call routine system_call is called through the interrupt mechanism. Its execution process is roughly divided into 4 steps:

1. Take the system call number and input parameters from the register, and then push the values ​​of these registers into the kernel stack. Search the system call dispatch table according to the system call number and find the system call service routine (a kernel function).

2. Call the found system call service routine.

3. Pop the return value of the system call service routine off the stack and save it in the register again.

The system call routine system_call described above is executed in the kernel space. Before execution, the system call number and input parameters have been stored in the register, and this storage process is completed by the user space code. In fact, as mentioned in the first section, every real system call basically has a library function that encapsulates it. Generally, the system call number and input parameters are saved in this library function. When the system call routine system_call is executed, the return value is passed back to the user space library function through the register.

The above is the detailed content of What is the purpose of system call. For more information, please follow other related articles on the PHP Chinese website!