Operating systems Chapter 6

Mechanism: Limited Direct Execution

• Direct Execution Protocol (Without Limits)
  The direct execution is contrast with the idea of limited direct execution, that is, any process can issue I/O request to disk or gaining more resources, which as fast as will expect.

  • 

• Limited Direct Execution Protocol (Restricted Operations)
  Since some programs in processes will require operations or access address invalid maliciously or accidentally, it will make error on OS. Therefore, we must put other notion to solve this question.
  So we introduce two new processor modes:

  • User mode:
    The code run in the mode restricted in what it can do, for example, can not issue I/O request, otherwise, it will raising an exception.
  • Kernel mode:
    The Operating system(or kernel) (only)run in it. In this mode, any codes can run what it likes, including privileged operations such as issuing I/O requests and executing all types of restricted instructions.

  However, if any user's process want to issue I/O request but it is restricted mode. So how we invoke some function? Clearly, we must mention other notion.

  • system call:
    This is a function that all modern hardware provides for user program. Depend on it, user process can do some restricted operation.

• Trap
  We know that user process can invoke system call to do some restricted operation, so how it do it?

  • Trap instruction
    To execute a system call, a program must execute a special trap instruction, this instruction simultaneously jumps into the kernel and raises the privilege level to kernel mode; once in the kernel, the system can now perform whatever privileged operations are needed (if allowed), and thus do the required work for the calling process. When finished, the OS calls a special return-from-trap instruction, which, as you might expect, returns into the calling user program while simultaneously reducing the privilege level back to user mode.

  We have known that using system call by trap instruction will change user process to kernel process, so how every process store its register(process's machine state) and ensure its restore currently? Carefully, on x86, for example, the processor will push the program counter, flags, and a few other registers onto a per-process kernel stack; the return-fromtrap will pop these values off the stack and resume execution of the usermode program.

  • Trap handler and Trap table
    We have been solved the problem that it change in two mode, however, how to ensure codes running kernel are valid? So the kernel should carefully control what code executes upon trap. The kernel does so by setting up a trap table at boot time. When the machine boots up, it does so in privileged (kernel) mode, and thus is free to configure machine hardware as need be. One of the first things the OS thus does is to tell the hardware what code to run when certain exceptional events occur. For example, what code should run when a hard-disk interrupt takes place, when a keyboard interrupt occurs, or when a program makes a system call? The OS informs the hardware of the locations of these trap handlers.Once the hardware is informed, it remembers the location of these handlers until the machine is next rebooted, and thus the hardware knows what to do (i.e., what code to jump to) when system calls and other exceptional events take place.To specify the exact system call, a system-call number is usually assigned to each system call. The user code is thus responsible for placing the desired system-call number in a register or at a specified location on the stack; the OS, when handling the system call inside the trap handler, examines this number, ensures it is valid, and, if it is, executes the corresponding code. This level of indirection serves as a form of protection; user code cannot specify an exact address to jump to, but rather must request a particular service via number.
    
  • Summary
    I will tell you the whole process in short.
    First, when operating system boot in kernel mode, the OS can free to configure machine hardware as need be, so it will initialize the Trap Table, which contain Trap Handler, and inform to hardware the address until OS reboot.
    Second, new process create as user mode(user process), only issuing some restricted opration and function, but the kernel can do any operation. Therefore, the user mode can do some restricted operation by system call, which can change user mode to kernel mode. In details, to execute a system call, there are pair instruction called Trap and return-from-trap, former let process jump into kernel and raise privilege simultaneously, latter will invoke when finished code run, return to the calling program and restore, update the state. So how to ensure the state currently in changing? Every process using its kernel-stack(notice,not the kernel, per-process have a kernel-stack) to store PC(program counter), flags, and registers(process's machine state) (puts arguments and system-call-number for the system call that issue the trap), the important part is Hardware, it store state in per-process's kernel-stack, and direct system call to suitable Trap handler in kernel.
    Third, how to ensure the code that run on kernel is valid? Obviously, by using Trap notion and system-call-number, the kernel can judge whether the code could be running. Additionally, the system-call-number by placing it in well-known locations(i.g stack or specific register) and when invoke some operation, examining the number.

• Switch between processes
  Maybe you think switch between processes is easy, right? The OS will decide to stop one process and swicth to another. But, it actually is a little bit tricky: specifically, if a process is running on the CPU, this by definition means the OS is not running. If the OS is not running, how can it do anything at all?
  So how can the operating system regain control of the CPU so that it can switch between processes?

  • A Cooperative Approach: Wait For System Calls
    In this style, the OS trusts the processes of the system to behave reasonably. Processes that run for too long are assumed to periodically give up the CPU so that the OS can decide to run some other task. In this style, most processes transfer control of the CPU to OS quite frequently by making system call, for example, to open a file and read it, or to send a message to another machine, or create a new process. Systems like this often include an explicit yield system call, which do nothing but transfer control to OS so that it can run other process. Not only that, they will transfer control to OS when do something illegal, such as divide zero, access memory that not valid. It will generate a trap to the OS, then will transfer control to OS to solve it. But, if the process that not run ideal? What happens, for example, a process that run a infinite loop and will never make a system call. So how do we deal with it?
  • A Non-Cooperative Approach: The OS Takes Control
    Simply, we can make what we called a useful way - reboot, but every times running unfriendly doing reboot feel like a stupid thing. In such a infinite loop, the code will run long time, so how to solve it? Time. Yes, we can set a device called timer interrupt, which can be programmed to raise so many times in some milliseconds. When the interrupt is raised, the currently running process is halt, and like switch on user mode to kernel mode, OS also pre-configure a interrupt handler like former reference Trap handler, so the OS can regain control of CPU. Moreover, the OS can do privilege operation in boot time, so that it will run the timer. After that, the OS will feel safety because of it will regain control of CPU in a certain period. Also, we can choose not to run timer in concurrency notion.
    Like mentioned above, the switch between processes also involved how to store state that ensure to restore currently. Of cause, we can solve it like what Trap and return-from trap do - store in per-process's kernel-stack.
  • Saving and restore Context
    When doing some operations that OS regain control of CPU, such as via system call or timer interrupt, the OS will decide whether continue to run former process or a new process, which are decide on scheduler, we will talk about it in next chapter. Now, we focus on if decide to run a new process, how the switch do and state stored.
    In switch operation, the OS will execute low-level piece of code which we refer to as a context switch. In short, the context switch do something simple: save some registers values for currently-executing process(on to kernel-stack), restore some for the soon-be-executing process(from its kernel-stack).
    To save the context of currently-running process, the OS will execute some low-level assembly code to save registers, PC, and the kernel-stack pointer of the currently-running process(notice, it's different on trap), and restore these, switch to the kernel-stack for soon-be-executing process. By switching stacks, the kernel(not kernel-stack, the kernel also OS) enters the call to switch code in the context of one process(the one be interrupt) and returns in the context of another(the soon-be-executing), the soon-be-executing will be the currently-executing, so the switch is complete.
    
    In this example, Process A is running and then is interrupted by the timer interrupt. The hardware saves its registers (onto its kernel stack) and enters the kernel (switching to kernel mode). In the timer interrupt handler, the OS decides to switch from running Process A to Process B. At that point, it calls the switch() routine, which carefully saves current register values (into the process structure of A), restores the registers of Process B (from its process structure entry), and then switches contexts, specifically by changing the stack pointer to use B’s kernel stack (and not A’s). Finally, the OS returns from-trap, which restores B’s registers and starts running it.
    Note that there are two types of register saves/restores that happen during this protocol, the first is when timer interrupt occurs, the user registers of the running process is implicit saved by the hardware, in its kernel-stack. The second is when the OS(kernel) decide to switch from A to B, in that case, the kernel rigesters are explicit saved by software(i.e, OS), but this time into memory in the process structure of the process. The latter action moves the system from running as if it just trapped into the kernel from A to as if it just trapped into the kernel from B.

In my machine, the context switch and change between user and kernel both cost (1 mu m), it sounds great, right?