User space and kernel space, process context and interrupt context [summary] "go"

Transferred from: http://www.cnblogs.com/Anker/p/3269106.html

1. Preface

Recent knowledge of the Linux kernel often sees user space and kernel space and process context and interrupt context. Look very familiar, half-day and can not say what is going on, what is the difference. The process of reading is often felt deceived, indefinitely feeling, very uncomfortable, and today a good combination of books and online information to summarize, deepen understanding.

2. User space and kernel space　

We know that the operating system is now using virtual memory, then for 32-bit operating systems, its addressing space (virtual storage space) is 4G (2 of 32). The core of the worry system is the kernel, which is independent of the normal application, has access to the protected memory space, and has all the permissions to access the underlying hardware device. In order to ensure that the user process can not directly manipulate the kernel, to ensure the security of the kernel, worry about the system to divide the virtual space into two parts, part of the kernel space, part of the user space. For the Linux operating system, the highest 1G bytes (from the virtual address 0xc0000000 to 0xFFFFFFFF) for the kernel to use, called the kernel space, and the lower 3G bytes (from the virtual address 0x00000000 to 0xBFFFFFFF) for each process to use, Called User space. Each process can enter the kernel through system calls, so the Linux kernel is shared by all processes within the system. Thus, from a specific process perspective, each process can have a virtual space of 4G bytes. The spatial allocation is as follows:

　　with user space and kernel space, the entire Linux internal structure can be divided into three parts, from the bottom to the top, in order: hardware----------------- as shown in the following:

　　Detailed Questions to note:

(1) kernel space is stored in the kernel code and data, and the process of user space is stored in the user program code and data. Both the kernel space and the user space are in virtual space.

(2) Linux uses a level two protection mechanism: level 0 for the kernel, and 3 for user programs.

　　Kernel state and User state:

(1) When a task (process) executes a system call and is executed in the kernel code, the process is said to be in the Kernel runtime State (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.

(2) when the process executes the user's own code, it is said to be in the user's running state (user state). At this point the processor runs 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.

Resources:

http://blog.csdn.net/f22jay/article/details/7925531

http://blog.csdn.net/zhangskd/article/details/6956638

Http://blog.chinaunix.net/uid-26838492-id-3162146.html

3. Process context and interrupt context

I'm looking at the third chapter of the book, "Linux kernel design and implementation". Process management, see the process context. The book says that when a program executes a system call or triggers an exception (soft interrupt), it falls into kernel space, which at this point represents the process execution and is in the context of the process. Look after still did not figure out, what is the process context, how on Google above a crazy search, summed up as follows:

The program in the execution process usually has the user state and the kernel state two states, the CPU is in the kernel state according to the context Environment further subdivision, therefore has the following three kinds of states:

(1) kernel state, running in the process context, the kernel represents the process running in the kernel space.
(2) The kernel state, running in the interrupt context, the kernel represents the hardware running in the kernel space.
(3) User mode, running in user space.

　　Context: Context is simply an environment.

User-space applications, through system calls, into the kernel space. At this time, the process of user space to pass a lot of variables, parameters of the value to the kernel, the kernel state when running the user process to save some register values, variables and so on. The so-called "process context" can be seen as the parameters that the user process passes to the kernel and the set of variables and register values that the kernel is going to save and the environment at that time.

In relation to a process, it is the environment at which the process executes. In particular, variables and data, including all register variables, process open files, memory information, and so on. The context of a process can be divided into three parts: User-level context, register context, and system-level contexts.

(1) User-level context: body, data, user stack, and shared storage area;
(2) Register context: Universal Register, Program Register (IP), processor status register (eflags), stack pointer (ESP);
(3) System level context: Process Control block task_struct, memory management information (mm_struct, Vm_area_struct, PGD, Pte), kernel stack.

When a process is scheduled, a process switch is a context switch. The operating system must switch all the information mentioned above to run the newly scheduled process. The system calls the mode switch. Mode switching is much easier compared to process switching, and saves time because the main task of mode switching is to switch the process register context.

The hardware passes the trigger signal, causing the kernel to call the interrupt handler and enter the kernel space. In this process, some variables and parameters of the hardware are also passed to the kernel, and the kernel is interrupted by these parameters. The so-called "interrupt context" can actually be seen as the hardware passes over the parameters and some other environment that the kernel needs to save (mainly the process environment that is currently interrupted). when interrupted, the kernel does not run on behalf of any process, it generally accesses only the system space and does not access the process space, and the kernel generally does not block when executed in an interrupt context.

The contents of the excerpt from Linux comments are as follows:

Process Context
-------------------------------------------
One of the most important parts of a process are the executing program code. This code was read in from a executable file and executed within the program's address space. Normal program execution occurs in User-space. When a program executes a system call or triggers an exception, it enters Kernel-space. At this point, the kernel are said to being "executing on behalf of the process" and are in process context. When in process context, the current macro is valid[7]. Upon exiting the kernel, the process resumes execution in User-space, unless a higher-priority process have become runnable In the interim (transition period), in which case the scheduler is invoked to select the higher priority process.

Other than process context there was interrupt context, in interrupt context, the system was not running on behalf O f a process, but was executing an interrupt handler. There is no process tied to interrupt handlers and consequently no process context.

System calls and exception handlers is well-defined interfaces into the kernel. A process can begin executing in kernel-space only through one of these interfaces – all access to the kernel is through These interfaces.

-------------------------------------------

Interrupt Context
-------------------------------------------
When executing a interrupt handler or bottom half, the kernel is in interrupt context.Recall That process context is the mode of operation the kernel are in while it's executing on behalf of a process-- For example, executing a system call or running a kernel thread. In process context, the current macro points to the associated task. Furthermore, because a process is coupled to the kernel in process context (because the process is connected to the kernel in the same way as the process above), process context can Slee P or otherwise invoke the scheduler.

Interrupt context, on the other hand, was not associated with a process. The current macro isn't relevant (although it points to the interrupted process). Without a backing process (because there is no process background), interrupt context cannot sleep-how would it ever reschedule? (or how to reschedule it again?) Therefore, cannot call certain functions from interrupt context. If A function sleeps, you cannot use it from your interrupt handler--this limits the functions so one can call from an Interrupt handler. (This is the limit on what functions can be used in an interrupt handler)

Interrupt context is time critical because the Interrupt handler interrupts other code. Code should is quick and simple. Busy looping is discouraged. This was a very important point; Always keep in mind that your interrupt handler have interrupted other code (possibly even another interrupt handler on a D Ifferent line!). Because of this asynchronous nature, it is imperative (must) that all interrupt handlers are as quick and as simple as Possibl E. As much as possible, work should is pushed out from the interrupt handler and performed in a bottom half, which runs at A more convenient time.

The setup of an interrupt handler ' s stacks is a configuration option. Historically, interrupt handlers did not receive (owned) their own stacks. Instead, they would share the stack of the process that they interrupted[1]. The kernel stack is a and a size; Typically, that's 8KB on 32-bit architectures and 16KB on 64-bit architectures. Because in this setup interrupt handlers share the stack, they must be exceptionally frugal (must be very economical) with what data they al Locate there. Of course, the kernel stack is limited to begin with, so all kernel code should be cautious.

A process is always running. When nothing else is schedulable, the idle task runs.

-------------------------------------------

A paragraph in the Linux full comment:

when a process executes, the values in all registers of the CPU, the state of the process, and the contents of the stack are referred to as the context of the process. When the kernel needs to switch to another process, it needs to save all the state of the current process, that is, to save the context of the current process so that it can be executed when the process is executed again. In Linux, the current process context is stored in the task data structure of the process. In the event of an outage, the kernel executes the interrupt service routine under the kernel state in the context of the interrupted process. At the same time, all resources that need to be used are preserved so that the execution of the interrupted process can be resumed at the end of the relay service.

References :

Http://www.cnblogs.com/hustcat/articles/1505618.html

http://mprc.pku.edu.cn/~zhengyansong/blog/?p=199

Http://blog.chinaunix.net/uid-26980210-id-3235544.html

User space and kernel space, process context and interrupt context [summary] "go"