Wednesday, September 29

We discussed one view of the layout of a project in memory that was at first puzzling.  The Bach book mentions one possible formulation in which the kernel occupies virtual memory addresses 0-4M-1 and the user process occupies virtual memory address 4M-4G-1.  The question was why virtual address space had to be shared between the process and the kernel.

The answer probably lies in the fact that the kernel runs in the context of a process.  That is, a process is considered to have both user and kernel code as part of its executable code.  When running in user mode, the program code of the process is the user's code and there is a set of "register triples" that point to the user's text, data, and stack in virtual memory.  For example, the first register in the first triple points to the page table for the code of the user program, the second register in the first triple has the starting virtual address of the user code, and the third register in the first register triple contains some control information.  When the same process is running in kernel mode there is a different set of "register triples" that point to the kernel text, data, and the u-area of the currently running process (there is no different pointer for the kernel stack, because it just grows on top of the stack that is the user's stack).

The kernel always accesses the u-area of the currently running process at the same virtual memory address.  So, it is up to the kernel when changing the context of a process to change the page table entry for virtual address translation so that this same virtual memory address maps properly to the new u-area of the new process.

We discussed the the context of a process in terms of the Bach book.  There are two parts of this context -- the user context and the system context.