ULK --- Chap3 Processes: Performing the Process Switch

A process switch may occur at just one one well-defined point: the schedule() function, which is discussed

at length in Chapter 7. Here, we are only concerned with how the kernel performs a process switch. Essentially,

every process switch consists of two steps:

1. Switching the Page Global Directory to install a new address space; we will describe this step in Chapter 9.

2. Switching the Kernel Mode stack and the hardware context, which provides all the information needed by

the kernel to execute the new process, including the CPU registers.

Again, we assume the prev points to the descriptor of process being replaced, and next to the descriptor of the

process begin activated. As we will see in Chapter 7, prev and next are local variables of the schedule() function.

　　　　　　　　　　　　　　　　　　　　　　　　　　The switch_to macro

The second step of the process switch is performed by the switch-to macro. It is one of the most hardware-dependent

routines of the kernel, and it takes some effort to understand what it does.

First of all, the macro has three parameters, called perv, next, and last. You might easily guess the role of prev

and next: they are just placeholders for the local variables prev and next, that is, they are input parameters that

specify the memory locations containing the descriptor address of the process being replaced and the descriptor

address of the new process, respectively.

First of all, the macro has three parameters, called prev, next, and last. You might easily guess the role of prev

and next: they are just placeholders for the local varaiables prev and next, that is, they are input parameters that

specify the memory locations containing the descriptor address of the process being replaced and the descriptor

address of the new process, respectively.

What about the third parameter, last ? Well, in any process switch three processes are involved, not just two.

Suppose the kernel decides to switch off process A and to activate the process B. In the schedule() function, prev

points to A's descriptor and next points to B's descriptor. As soon as the switch_to macro deactivate A, the execution

flow of A freezes.

Later, when the kernel want to reactivate A, it must switch off another process C (in general, this is different from

B) by executing another switch_to macro with prev pointing to C and next pointing to A. When A resumes its execution

flow, it finds its old Kernel Mode Stack, so the prev local varaible points to A's descriptor and next points to B's 

descriptor. The scheduler, which is now executing on behalf of process A, has lost any reference to C. This reference,

however, turns out to be useful to complete the process switch.

The last parameter of the switch_to macro is an output parameter that specifies a memory location in which the macro

writes the descriptor address of process C (of course, this is done after A resumes its execution). Before the process

switch, the macro saves in the eax CPU register the content of the variable identified by the first input parameter

prev --- that is, the prev local variable allocated on the Kernel Mode Stack of A. After the process swtich, when A has

resumed its execution, the macro writes the content of the eax CPU register in the memory location of A identified by

the third output parameter last. Because the CPU register doesn't change acroos the process switch, this memory

location receives the address of C's descriptor. In the current implementation of schedule(), the last paramter identifies

the prev local variable of A, so prev is overwritten with the address of C.

 

转载于:https://www.cnblogs.com/miaoyong/p/4961523.html