next up previous contents Back to Operating Systems Home Page
Next: Process Description and Control Up: Process control: architectural design Previous: Non-process kernel

Kernel executed within a process

In this case (which is common for OSs designed for small machines, e.g. minicomputer, PCs) the OS provides almost all its services within a user process's context, as if they were obtained through ``normal'' subroutine calls. However, these calls must be differentiated by some mechanism for this scheme to work correctly, This allows the implementation (in software) of system subroutines that put the processor in protected mode on entering, thus gaining access to all system resources, and return it in user mode on return. If the system is well designed, an attempt to gain privileged access by-passing the OS can be detected (and punished) because it invariably causes an interrupt, thus allowing the OS the gain CPU control once more.

In Fig 4 this scheme is represented in detail, as it is implemented in the UNIX operating system. Here a part of the PCB, called ``user area'', is stored in the process image: it contains those PCB data which are used only when the process is running, hence not needing to be stored in global kernel process tables. In particular, it contains a kernel stack, i.e. a stack used to manage kernel subroutines calls and parameter passing. Although a part of the process image, the user area cannot be addressed by the process: simply put, it's outside the range of valid addresses the process can generate (the ``user address space''), and an exception would be trapped if it tried to. When the process is running, the kernel accesses those data by remapping the the process image in a part of a shared memory area, the system address space, in which the kernel routines are executed.

  
Figure 4: Logical view of the process image in the UNIX OS



Franco Callari