Processes

Friday, September 10, 2004

Functional Design of Unix

We continued to discuss the functional design of Unix based on the diagram of the last lecture. 

We paid particular attention to the way Unix works in terms of the services it provides.  This is essentially the way most operating systems work.  In order for a program running in user mode to do anything with any hardware devices, it does so by calling a system service (procedure).  This is done by issuing a TRAP (also called a SYSTEM_CALL) instruction.  This instructions

bulletsets the u/s bit to supervisor
bulletsaves the current PC, so that the return from the kernel can be made to the proper place
bulletsaves the TRAP parameter, if there is one, so that the kernel knows which system service is being referenced
bulletsets the PC to the address of the TRAP handling service routine in the kernel

All of these actions are performed in one uninterruptible instruction execution cycle.  On the next cycle, the instruction executed is therefore the first instruction of the trap handling procedure in the kernel, which begins executing in supervisor mode.

Process States in Unix

The diagram of the process states in Unix is given below. (This is the standard simple first look at process states in Unix; there are actually quite a few more states).

The interesting thing that comes out of this diagram is that processes in Unix include both the user side of the program and the kernel.  When a user writes a program, say in C, that program may call a number of the system functions in the systems library (e.g., printf).  These functions in turn call system resources to accomplish their tasks.  All of these things are linked together by the compiler to form a complete program, so by extension, the kernel becomes part of the user program.  (Actually, the kernel does not become part of the user program, but it is logically treated that way).