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.