User-State and kernel-state explanation

When a task (process) executes a system call and is executed in the kernel code, we say that the process is in the kernel run state (or simply the kernel state). At this point the processor is executed in the highest privileged (level 0) kernel code. When the process is in the kernel state, the kernel code that executes will use the kernel stack of the current process. Each process has its own kernel stack. When the process executes the user's own code, it is said to be in the user's running state (user state). That is, the processor is running in the least privileged (level 3) user code. When the user program is being executed and the program is interrupted abruptly, the user program can also be symbolically referred to as the kernel state in the process. Because the interrupt handler will use the kernel stack of the current process. This is somewhat similar to the state of a process that is in a kernel state.

1, when the system calls into the nuclear mentality. Linux operates on hardware only in a nuclear mindset, which can be controlled by a write driver. Operating hardware in the user state will cause core dump.
2, should pay attention to distinguish system calls and general functions. System calls are provided by the kernel, such as read (),write (),Open () , and so on. The general function is provided by the Library of functions in the package, such as sin (),cos () , and so on. There is no difference between the two syntaxes.
3, the general situation: the system call runs in the kernel mentality, the function runs in the user state. But there are also some functions that use system calls internally (such as fopen), such that the function calls in the system call is into the kernel mentality, and other times it runs in the user state.

The

is probably     when the user program calls the system's API, it generates interrupts, enters the kernel-state API, and after processing completes, interrupts and exits again, returning the call function of the user state.    
   user    api   -->    Interrupt    -->    kernel    api   -->     Interrupt

---------------------------------------------------------------------
In a nutshell, a process begins executing kernel code by executing a system call, which we call the process in the kernel state. A process executes the application's own code, which says the process is in the user state.
The Intel x86 architecture has several operating levels of CPUs, from 0--3, 0 to the highest level, and 3 to the lowest level
For different levels, there are a lot of restrictions, such as the traditional in, out instruction, is the port input and output instructions, in the 0 level is can be used, but in the 3 level will not be used, you use to create traps, tell you wrong, of course, there are a lot of restrictions, not just this point.
Operating system is to take advantage of this feature, when the operating system's own code runs, the CPU is cut into 0 levels, when the user's program is only let it run at level 3, so that if the user's program wants to do something to destroy the system, there is no way to do
Of course, the low-level program is not able to upgrade themselves to high-level, that is, the user program is running at 3, he wants to turn himself into a level 0 himself is not able to do, unless the operating system to help, using this feature, the operating system can control the operation of all programs, to ensure the security of the system. Usually the operating system runtime is called the kernel State (because it is the operating system Kernel runtime State), and the normal user program runs the level called the user state ...
When the operating system just boot, the CPU is in real mode, then the equivalent is 0 levels, so the operating system automatically get the highest permissions, and then cut to the protection mode is 0 levels, then the operating system has taken the lead, become the highest level of the runner, because your program is loaded by the operating system, So when it loads you up, you set your running status to 3 levels, that is, the lowest level, and then let you run, so there is no way, you can only run at the lowest level, because there is no way to raise themselves from the low level to advanced, this is the operating system in the kernel can manage user programs, kill the user program reasons.

1. Conceptual differences between the user and kernel states

What is the user state, what is the kernel state, these two basic concepts have been understood not very clearly, the root cause of the personal feel is because most of the time we write programs in the focus of attention and perspective on the implementation of the function and the logic of the code, first look at an example:

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, is actually executed a fork (), to generate a new process, from a logical point of view, it is determined that if the fork () returned is 0 print the relevant statement, and then the function finally printed a sentence to execute the complete testfork () function. Code execution logic and function is so simple, a total of four lines of code, from the top to the next sentence of execution, completely see where there is the concept of user state and process state.

If the previous two is a static observation of the point of view, we can also from a dynamic point of view of the code, that is, it is converted to the CPU execution of instructions after loading the execution process, this program is a dynamic execution of the sequence of instructions. What code is loaded and how it is loaded is closely related to the operating system.

2) Privilege level

People familiar with the unix/linux system know that fork work is actually done in the way the system calls to complete the corresponding functions, the specific work is carried out by the sys_fork responsible for implementation. In fact, whether it is UNIX or Linux, for any operating system, the creation of a new process is a core function, because it has to do a lot of work at the bottom, consume the physical resources of the system, such as allocating physical memory, copying information from the parent process, copying the Settings page Table of Contents page, etc. These obviously cannot be arbitrarily allowed to do, so it naturally leads to the concept of the privilege level, it is clear that the most critical power must be implemented by a highly privileged program, so as to achieve centralized management, reduce access and use of limited resources conflict.

Privilege level is obviously a very effective means of management and control program execution, so there is a lot of support on the hardware to the privilege level, on the Intel x86 architecture of the CPU has 0~3 four privileged, 0 highest, 3 lowest, the hardware on the execution of each instruction will be the command of the privilege level of the corresponding check, The associated concepts are CPL, DPL, and RPL, which are no longer too much elaborated here. Hardware has provided a set of privilege-level use of the relevant mechanisms, software is a good use of the problem, which is the operating system to do, for Unix/linux, only use 0 level privilege and 3 privilege level. That is to say, in the unix/linux system, a command that works at level 0 privilege has the highest power available to the CPU, while an instruction at level 3 privilege has the lowest or most basic power provided by the CPU.

3) User state and kernel state

Now we understand the user-state and kernel-state from the privilege-level scheduling, when the program runs at level 3 privilege level, it can be called as running in the user state, because this is the lowest privilege level, is the normal user process to run the privilege level, most users directly face the program is running in the user state; When the program is running at level 0 privilege level, it can be called running in the kernel state.

Although there are many differences between the user-state and kernel-state programs, the most important difference is the difference in privilege levels, that is, the difference in power. Programs running in the user state cannot directly access the operating system kernel data structures and programs, such as Testfork () in the above example can not directly call Sys_fork (), because the former is working in the user state, belongs to the user program, and Sys_fork () is working in the kernel State, belongs to the kernel state program.

When we execute a program in the system, most of the time is run in the user state, when it needs the operating system to help complete some of its power and ability to complete the work will be switched to the kernel state, such as Testfork () initially run in the user state process, when it calls Fork () the final trigger Sys_ When the fork () is executed, it switches to the kernel state.

2. Conversion of user state and kernel state

1) 3 Ways to switch the user state to the kernel state

A. System call

This is a way for the user-state process to switch to the kernel state actively, the user-state process through the system call request using the operating system provided by the service program to complete the work, such as in the preceding example, fork () is actually executed a new process to create a system call. The core of the system call mechanism is to use an interrupt that the operating system is particularly open to the user, such as an int 80h interrupt for Linux.

B. Exceptions

When the CPU executes a program running in the user state, some pre-unknown exception occurs, which triggers the current running process to switch to the kernel-related program that handles this exception, and then goes to the kernel state, such as a page fault.

C. Interruption of peripheral equipment

When the peripheral device completes the user requested operation, the CPU is signaled to the corresponding interrupt, then the CPU will suspend execution of the next instruction to be executed to execute the handler corresponding to the interrupt signal, if the previously executed instruction is a user-state program, Then the process of this conversion will naturally occur from the user state to the kernel state switch. For example, the disk read and write operation is completed, the system will switch to the hard disk read and write interrupt handler to perform subsequent operations.

These 3 methods are the most important way for the system to go to the kernel state from the user state at runtime, where the system call can be thought to be initiated by the user process, and the exception and the peripheral device interrupt are passive.

User-State and kernel-state explanation