If you are taking an undergraduate operating systems course, you should already have some idea of what a computer program does when it runs. If not, this book (and the corresponding course) is going to be difficult so you should probably stop reading this book, or run to the near- est bookstore and quickly consume the necessary background material before continuing (both Patt & Patel (PPC3] and Bryant & O'Hallaron[BOH10] are pretty great books). So what happens when a program runs?
Well, a running program does one very simple thing: it executes in- structions. Many millions (and these days, even billions) of times ev ery second, the processor fetches an instruction from memory, decodes it (Le.. figures out which instruction this is), and executes it (ie., it does the thing that it is supposed to do, like add two numbers together, access memory, check a condition, jump to a function, and so forth). After it is done with this instruction, the processor moves on to the next instruction, and so on, and so on, until the program finally completes'[1]
Thus, we have just described the basics of the Von Neumann model of computing [2] . Sounds simple, right? But in this class, we will be leaming that while a program runs, a lot of other wild things are going on with the primary goal of making the system easy to use.
There is a body of software, in fact, that is responsible for making it easy to run programs (even allowing you to seemingly run many at the same time), allowing programs to share memory, enabling programs to interact with devices, and other fun stuff like that. That body of software
[1] Of course, modem processors do many bizarre and frightening things underneath the hood to malar programmuster, guling multiple intructions, and even i ing and completing them out of order! But that is not our concem here we am just concerned with the sample model most programs assume that instructions seemingly execute one at a main an orderly and sequential fashion
[2] Von Neum was me of the only pics of computing systems. He also did pioneer ing work on game theory and atomic humb and played in the NBA or yours. OK, me those things isn't true
THE CRUX OF THE PROBLEM:
How To VIRTUALIZE RESOURCES
One central question we will answer in this book is quite simple: how does the operating system virtualize resources? This is the crux of our problem. Why the OS does this is not the main question, as the answer should be obvious: it makes the system easier to use. Thus, we focus on the how what mechanisms and policies are implemented by the OS to attain virtualization How does the OS do so efficiently? What hardware support is needed?)
We will use the "crux of the problem", in shaded boxes such as this one, as a way to call out specific problems we are trying to solve in building an operating system. Thus, within a note on a particular topic, you may find one or more cruces (yes, this is the proper plural) which highlight the problem. The details within the chapter, of course, present the solution, or at least the basic parameters of a solution.
is called the operating system (OS)[3] , as it is in charge of making sure the system operates correctly and efficiently in an easy-to-use manner.
The primary way the OS does this is through a general technique that we call virtualization. That is, the OS takes a physical resource (such as the processor, or memory, or a disk) and transforms it into a more gen- eral, powerful, and easy-to-use virtual form of itself. Thus, we sometimes refer to the operating system as a virtual machine.
Of course, in order to allow users to tell the OS what to do and thus make use of the features of the virtual machine (such as running a pro- gram, or allocating memory, or accessing a file), the OS also provides some interfaces (APIs) that you can call. A typical OS, in fact, exports a few hundred system calls that are available to applications. Because the OS provides these calls to run programs, access memory and devices, and other related actions, we also sometimes say that the OS provides a
standard library to applications. Finally, because virtualization allows many programs to run (thus shar- ing the CPU), and many programs to concurrently access their own in- structions and data (thus sharing memory), and many programs to access devices (thus sharing disks and so forth), the OS is sometimes known as a resource manager. Each of the CPU, memory, and disk is a resource of the system; it is thus the operating system's role to manage those resources, doing so efficiently or fairly or indeed with many other possible guals in mind. To understand the role of the OS a little bit better, let's take a look at some examples.
[3] Another early name for the OS was the supervisor or even the master control program. Apparently, the latter sunbed a little verzaken (that man Tram for details) anal thus, thanktully "operating system caught on instead.