University of California, Davis
©2001, N. Matloff
May 30, 2001
1.1 It's Just a Program!
1.2 What Is an OS for, Anyway?
1.3 A Bit More on System Calls
1.4 Making These Concepts Concrete: Commands You Can Try Yourself 2 System Bootup
3 Application Program Loading
4.1 Many Processes, Taking Turns
4.2 Example of OS Code: Linux for Intel CPUs
4.3 Process States
4.4 How the Process Tree Is Built
4.5 Making These Concepts Concrete: Commands You Can Try Yourself 5 The Use of Virtual Memory for Memory Management and Protection 5.1 Make Sure You Understand the Goals
5.2 Example of Virtual Nature of Addresses
5.3 Overview of How the Goals Are Achieved
5.4 Creation and Maintenance of the Page Table
5.5 Details on Usage of the Page Table
5.5.1 Virtual-to-Physical Address Translation, Page Table Lookup 5.5.2 Page Faults
5.5.3 Access Violations
5.6 Improving Performance
5.7 Intel Page Tables
5.8 Making These Concepts Concrete: Commands You Can Try Yourself A Hardware Interrupts
A.1 General Operation
A.2 Some Details for Intel CPUs and PCs
1.1 It's Just a Program!
First and foremost, it is vital to understand that an operating system (OS) is just a program - a very large, very complex program, but still just a program. The OS provides support for the loading and execution of other programs (which we will refer to below as ``application programs''), and the the OS will set things up so that it has some special privileges which user programs don't have, but in the end, the OS is simply a program. For example, when your program, say a.out,1 is running, the OS is not running, Thus the OS has no power to suspend your program while your program is running - since the OS isn't running! This is a key concept, so let's first make sure what the statement even means. What does it mean for a program to be ``running'' anyway? Recall that the CPU is constantly performing its fetch/execute/fetch/execute/... cycle For each fetch, it fetches whatever instruction the Program Counter (PC) is pointing to. If the PC is currently pointing to an instruction in your program, then your program is running! Each time an instruction of your program executes, the circuitry in the CPU will update the PC, having it point to either the next instruction (the usual case) or an instruction located elsewhere in your program (in the case of jumps). The point is that the only way your program can stop running is if the PC is changed to point to another program, say the OS. How might this happen? Other than cases involving bugs in your program, there are only two ways this can occur:
Your program can voluntarily relinquish the CPU to the OS. It does this via a system call.which is a call to some function in the operating system which provides some useful service. For example, suppose the C source file from which a.out was compiled had a call to scanf(). The scanf() function is a C library function, which was linked into a.out during compilation of a.out. But scanf() itself calls read(), a function within the OS. So, when a.out reaches the scanf() call, that will result in a call to the OS, but after the OS does the read from the keyboard, the OS will return to a.out.2 The other possibility is that a hardware interrupt occurs. (See Appendix Afor an introduction to hardware interrupts, and their implementation on Intel-based machines.) This is a signal - a physical pulse of current along an interrupt-request line in the bus - from some input/output (I/O) device such as the keyboard to the CPU. The circuitry in the CPU is designed to then jump to a place in memory which we designated upon bootup of the machine. This will be a place in the OS, so the OS will now run. The OS will attend to the...