"Linux kernel design and implementation of the system call of reading notes"

1. The concept of system invocation

To interact with processes running on user space, the kernel provides a set of excuses. Through this interface, applications can access hardware devices and other operating system resources. This set of excuses plays a role as an emissary between the application and the kernel. At the same time, this set of interfaces also ensure that the system is stable and reliable, to avoid the application of reckless, causing trouble. The system invocation of the Linux system is provided as part of the C library, as shown in the instance of the call process:

From the programmer's point of view, system calls don't matter, they just have to deal with the API. Instead, the kernel only deals with system calls, library functions, and how the application uses system calls that are not the kernel's concern.

2. Handlers for system calls

User-space programs cannot execute kernel code directly. They cannot directly invoke functions in kernel space because the kernel resides on a protected address space. The system becomes insecure if the process can read and write directly to the kernel's address space.

Therefore, the application should notify the system in some way, telling the kernel that it needs to perform a system call and wants the system to switch to the kernel state. This is accomplished by a soft interrupt: by throwing an exception that causes the system to switch to the kernel state to point to the exception handler, at which point the exception handler is the handler for the system call. The soft interrupt on the x86 system is generated by the Int $0x80 directive. This instruction triggers an exception that causes the system to switch to the kernel too and executes the 128th exception handler, which is the system call handler. This handler name is aptly named System_call ().

Because all system calls fall into the same way as the kernel, it is not enough to get into kernel space, and you must pass the system call number to the kernel. On x86, the system call number is passed to the kernel through the EAX register. Before being trapped in the kernel, the user space will have the corresponding system call number in EAX. This allows the system call handler to get the data from the EAX once it is run. An instance of the Execute read () system call is as follows:

In addition to the system call number, some external parameter inputs are required for most system calls. On x86 systems, EBX, ecx, edx, ESI, and EDI store the first five parameters in order (less than six or six parameters are required). The return value of the user space is also the register to implement.

3. System call Context

The kernel is in a process context when it executes system calls. The current pointer points to the present task, which is the process that raised the system call. In the context of a process, the kernel can hibernate and can be preempted. This means that even in kernel space, the current process can be preempted by other processes. Because the new process can perform the same system call, the system call must be guaranteed to be reentrant. When the system call returns, control is still in System_call (), and it will eventually be responsible for switching to user space and allowing the user to continue the execution.

"Linux kernel design and implementation of the system call of reading notes"