Detailed description of user and core states, process switching, and system calling principles

Detailed description of user and core states, process switching, and system calling principles
1) Example

void testfork(){  if(0 = = fork()){    printf(“create new process success!\n”);     }   printf(“testfork ok\n”);  }  

This code is very simple. From a functional point of view, it means that a fork () is actually executed to generate a new process. From a logic point of view, it is determined that if fork () if the returned result is, the related statement is printed, and then the function is printed again to execute the complete testfork () function. The line logic and functions of the Code are so simple. There are four lines of code that can be executed in one sentence from top to bottom. 2) privileged level

If we look at the previous two static observations, we can also look at the code from a dynamic perspective, that is, the process of loading and executing the code after it is converted into a CPU-executed command, in this case, this program is a sequence of dynamically executed commands. The Code loaded is closely related to the operating system.

 

Anyone familiar with Unix/Linux systems knows that fork's work is actually done by calling the system. The specific work is implemented by sys_fork. In fact, whether it is Unix or Linux, for any operating system, creating a new process is a core function, because it requires a lot of bottom-layer meticulous work, consuming the physical resources of the system, for example, allocating physical memory, copying related information from the parent process, copying the page Directory and page table of setting pages, etc. These obviously cannot be done by any program, so the concept of privilege level is naturally introduced. Obviously, the most critical power must be implemented by High-level programs, so that centralized management can be achieved and access and use conflicts of limited resources can be reduced.

 

The privileged level is obviously a very effective way to manage and control program execution. Therefore, the hardware provides a lot of support for the privileged level. For Intel x86 architecture CPUs, there is a total of 0 ~ Three or four privileged levels, with the highest level 0 and the lowest level 3. When executing each command on the hardware, the system checks the privileged level of the command, related concepts include CPL, DPL, and RPL. The hardware has provided a set of privileged-level usage mechanisms, and the software is naturally a matter of good use. This is what the operating system wants to do. For Unix/Linux, only level 0 and Level 3 are used. That is to say, in Unix/Linux systems, a privileged command has the highest power that the CPU can provide, A command that works at three levels of privilege has the lowest or most basic power provided by the CPU.
3) user and Kernel The kernel state and user State have their own memory ing, that is, their own address space.
The user space application enters the kernel space through the system call. The kernel indicates that the process runs in the kernel space, which involves context switching. The user space and the kernel space have different address ing, general or dedicated register groups, the user space processes need to pass a lot of variables and parameters to the kernel. The kernel also needs to save some registers and variables of the user process so that the system can return to the user space for further execution after the call is completed.

The so-called "process context" refers to the value in all the registers of the CPU, the status of the process, and the content on the stack when a process is executed. When the kernel needs to switch to another process, it needs to save all the statuses of the current process, that is, to save the context of the current process, so that when the process is re-executed, it can restore the status of the switch and continue to execute.

 

Now we can better understand the user State and kernel state from the perspective of privileged scheduling. When the program runs on a three-level privileged level, it can be called running on the user State, because this is the lowest privilege level, it is the privileged level for normal user processes to run. Most of the programs that users directly face are running in the user State. If the program runs in the privileged level, it can be called running in the kernel state.

 

Although there are many differences between programs in user mode and kernel mode, the most important difference lies in the difference in privilege level, that is, the difference in power. The program running in the user State cannot directly access the data structure and program of the operating system kernel. For example, testfork () in the preceding example cannot directly call sys_fork (), because the former is a user-State program, while sys_fork () is a kernel-State program.

 

When we execute a program in the system, most of the time is running in the user State, when the operating system is required to help complete some work that it does not have the power and ability to complete, it will switch to the kernel state. For example, testfork () initially runs under the user State process, when it calls fork () and finally triggers the execution of sys_fork (), it switches to the kernel state.

4) Conversion of user and kernel states 1. User-mode switch to kernel-mode A. System Call This is a way for a user-state process to actively switch to the kernel state. the user-state process applies to use the service programs provided by the operating system through system calls to complete the work, such as fork () in fact, a system call is executed to create a new process. The core of the system call mechanism is to use an interrupt that is especially open to users by the operating system, for example, the int 80 h interrupt of Linux.
B. Exceptions Some unknown exceptions occur when the CPU runs a program in the user State. In this case, the current running process is triggered to switch to the kernel-related program that handles the exception, it is also switched to the kernel state, such as a page missing exception.
C. Peripheral Device interruption After the peripheral device completes the user request, it sends an interrupt signal to the CPU, at this time, the CPU will suspend the execution of the next command to be executed and then execute the processing program corresponding to the interrupt signal. If the previously executed command is a user-State program, the conversion process naturally changes from user to kernel. For example, after the hard disk read/write operation is completed, the system switches to the hard disk read/write Interrupt Processing Program for subsequent operations.

These three methods are the most important way for the system to switch from the user State to the kernel state at runtime. system calls can be considered as actively initiated by the user process, exceptions and peripheral device interruptions are passive.

2. Specific switchover operations

From the trigger method perspective, we can consider that there are three different types mentioned above, but from the final completion of switching from the user State to the kernel state, the key steps involved are completely consistent and there is no difference. They are equivalent to executing an interrupt response process, because system calls are actually implemented by the interrupt mechanism, the handling mechanism of exceptions and interruptions is basically the same, and the specific differences between them are not described here. The details and steps of the interrupt processing mechanism are not analyzed too much here. The steps involved in switching from user mode to kernel mode include:

 

[1] extract the ss0 and esp0 information of the kernel stack from the descriptor of the current process.

 

[2] use the kernel stack pointed to by ss0 and esp0 to save the cs, eip, eflags, ss, and esp information of the current process.The process also completes the switching from the user stack to the kernel stack, and saves the nextCommand.

 

[3] load the cs and eip information of the interrupt processing program previously retrieved by the interrupt vector into the corresponding register and start When the interrupt processing program is executed, the program in the kernel state is executed.