The complete set of process states:

• Executing in user mode
• Executing in kernel mode
• Ready to run
• Sleeping in memory
• Ready to run, but in swap space (covered later)
• Sleeping in swap space
• Preempted (the process is returning from kernel to user mode, but the kernel preempts it and does a context switch to schedule another process. Very similar to state 3)
• Newly created. Not ready run, nor sleeping. (This is the start state for all processes except process 0)
• The process executed exit system call and is in the zombie state. The process no longer exists, but it leaves a record containing an exit code and some timing statistics for its parent process to collect. The zombie state is the final state of a process.

When the parent process executes the fork system call model and it moves into a state where it is ready to run (3 or 5) at that time the process enters the created state.

The scheduler will eventually pick the process and the process enters the 'kernel running' state where it completes its part of the fork system call. After the completion of the system call, it may move to the 'user running'. When interrupts occur (such as system call), it again moves to the state 'kernel running'.

After completing the task of the interrupt the kernel may decide to schedule another process to execute, so the first process enters the state 'preempted'. The state preempted is actually same as the state ready to run in memory, but they are denoted separately to stress that a process executing in kernel mode can be preempted only when it is about to return to user mode. Consequently, the kernel could swap a process from the state preempted if necessary. Eventually, it will return to the 'user running' again.

When the system call is executed, it leaves the state user running and enters the state kernel running. If in kernel mode, the process needs to sleep for some reason (such as waiting for I/O), it enters the state asleep in memory. When the event on it which it has slept, happens, the interrupt handler awakens the process, and it enters the state ready to run in memory.

Suppose the system is executing many processes that do not set at the same time into main memory, then the swapper (process 0) swaps out a process to make space for another process that is in the state ready to run swapped. When forcefully takes from main memory, the process enters the state ready to run swapped. Finally, swapper chooses the process as most eligible to run and it re-enters the state ready to run in memory. And then when it is scheduled, it will enter the state kernel running. When a process completes and invokes exit system call, thus entering the states kernel running and finally, the zombie state.

Some state transitions can be managed by the users, but not all. User can create a process. But the user has no control over when a process transitions to sleeping in memory to sleeping in the swap, or ready to run in memory to ready to run in the swap, etc. A process can make a system call to transition itself to kernel running state. But it has no control over when it will return from kernel mode. Finally, a process can exit whenever it wants, but that is not the only reason for exit to be called.

Two kernel data structures describe the state of a process: the process table entry and the u-area as we have studied already. The process table contains information that should be accessible to the kernel and the u-area contains the information that should be accessible to the process only when it's running. The kernel allocates space for u-area only when creating a process. It does not need u-area for process table entries that do not have processes. For example, the process table entries that contain the information about the kernel context, do not have processes.

The fields in the process table and u-area have discussed already.

Layout of the Kernel

The kernel runs in the context of a process. But its virtual address space is completely independent of processes. When the system starts up, the kernel is loaded into memory and required page tables and registers are loaded with necessary data. Most of the hardware systems divide a process address space into many parts, user and kernel being two of them. When in user mode, access to kernel page tables is restricted. When the process switches to kernel mode, only then it can access kernel page tables. Some system implementations try to allocate the same physical pages to the kernel, keeping the translation function, an identity function. See the example given below