6 Mechanism: Limited Direct Execution

1. The first is performance: how can we implement virtualization without adding excessive overhead to the system? The second is control: how can we run processes efficiently while retaining control over the CPU? Control is particularly important to the OS, as it is in charge of resources; without control, a process could simply run forever and take over the machine, or access information that it should not be allowed to access.
2. Attaining performance while maintaining control is thus one of the central challenges in building an operating system

6.1 Basic Technique: Limited Direct Execution

Create entry for process list

Allocate memory for program

Load program into memory

Set up stack with argc/argv

Clear registers

Execute call main()

                                                                  Run main()

                                                                  Execute return from main

Free memory of process

Remove from process list

6.2 Problem #1: Restricted Operations

ASIDE: WHY SYSTEM CALLS LOOK LIKE PROCEDURE CALLS

1. You may wonder why a call to a system call, such as open() or read(), looks exactly like a typical procedure call in C; that is, if it looks just like a procedure call, how does the system know it’s a system call, and do all the right stuff?
2. The simple reason: it is a procedure call, but hidden inside that procedure call is the famous trap instruction. More specifically, when you call open() (for example), you are executing a procedure call into the C library.
3. Therein, whether for open() or any of the other system calls provided, the library uses an agreed-upon calling convention with the kernel to put the arguments to open in well-known locations (e.g., on the stack, or in specific registers), puts the system-call number into a well-known location as well (again, onto the stack or a register), and then executes the aforementioned trap instruction.
4. The code in the library after the trap unpacks return values and returns control to the program that issued the system call.
5. Thus, the parts of the C library that make system calls are hand-coded in assembly, as they need to carefully follow convention in order to process arguments and return values correctly, as well as execute the hardware-specific trap instruction.
6. And now you know why you personally don’t have to write assembly code to trap into an OS; somebody has already written that assembly for you.
7. There is one important detail left out of this discussion: how does the trap know which code to run inside the OS? Clearly, the calling process can’t specify an address to jump to (as you would when making a procedure call); doing so would allow programs to jump anywhere into the kernel which clearly is a bad idea