https://pages.cs.wisc.edu/~remzi/OSTEP/intro.pdf

Introduction

• What is an Operating System? What does it do for us?
  • No need for the complete list for now. Just get student ideas.
• Suppose I were to give you a computer and a compiler – nothing else (e.g., no operating system.)
  • Also, for now, suppose that you are only ever going to run one program at a time on this machine (e.g., high-powered weather simulation)
  • What else do you need to make practical use of this machine?
• A standard library to handle things like printing, stdin, and writing to files (among many others)
• Bigger picture: This standard library is an abstraction of the various devices: It abstracts the details of the various hardware devices so that
  1. Programmers don’t have to worry about details that aren’t important (key to conveniently/efficiently writing code for a given machine).
  2. Programmers can use a single interface to interact with a variety of devices. Thus, writing code for a variety of machines (or a variety of devices on one machine) is much more straightforward. (key to writing code for many machines — even if not at one time. This isn’t necessarily about portability, but rather the ability to write code efficiently.)
• Remember: One main aspect of abstraction is separating interface from implementation.
• Let’s step up abstraction a level. Notice that we use the same interface for writing to files, the keyboard, other processes, a network connection (i.e., many languages have a concept of a Stream with a print method. The other end of the stream can be attached to a wide variety of sources and sinks) This is a kind of virtualization: A stream is not an actual physical resource, but an abstract concept that stands in for an underlying resource.

• Virtualization is the first key service of Operating Systems.

• Suppose your program does a lot of reading and writing from the disk.
  • What are some of the inefficiencies of running your single program on this computer?
  • The system is idle when the program has to pause to wait for I/O.
• Propose a solution
  • When one program is blocked, run another.
• When we do this, we virtualize the CPU: We present an abstraction of a CPU that is separate from the real CPU. There can be many more virtual CPUs than real CPUs.
  • When I was an undergrad, this was one CPU and many programs.
  • Today it is many CPUs (i.e, “core”) and many more programs.
• When we virtualize a CPU, what other issues do we introduce?
  • Privacy / Security
  • Concurrency (Second key OS concept)
• Fourth main topic is Persistence.

Protection

• Standard Library: Library of commonly used code – makes the computer easy to use.

• To allow different users to securely share a system, there needs to be enforced protection.
• Some activity (e.g., opening files) must be restricted to the OS (or other trusted code).
• System Calls are a set of routines tha run “inside” the OS.
• CPU must be in “protected” mode to execute certain instructions (e..g, I/O).
• Chapter 7 explains protected mode and how system calls work.

• talk about “user space” and “kernel space”.

• I’ll tend to talk about the Standard Library as “user space” code and system calls as “kernel space” code – although that distinction isn’t strict.

Virtual Memory

• Run ./cpu "A"
• Now run ./cpu "A"& ; ./cpu "B" & ; ./cpu "C" & ; ./cpu "D" & ...
• Think about how memory works in the MIPS CPU.
• If these programs are running concurrently, they can’t all be using the same memory addresses at the same time. Thus, in addition to “virtualizing” the CPU, we also need to virtualize memory.
  • Each process’s &counter needs to have a different physical memory location.
• How to virtualize memory (but share it when appropriate) is a major topic.
• Absurdly high-level idea: Give each process a “base” register and make the address we see in the program an offset. (Obviously the real approach is more complicated.)

Concurrence

• Run ./threads 1000
• Now run ./threads 100000
• Explain how ++counter is not atomic.

Design Considerations

• List some design considerations:
  • Easy to use
  • Minimal overhead
  • protection
  • isolation
  • reliability
  • energy efficiency

OS History

• Just libraries (programs run in batch mode “by hand”)
• Protection (many people sharing a single machine)
• Multi-programming (swap another program in when one blocked on I/O)
  • After all, computers were expensive.
  • UNIX
• PCs were a step backward (in terms of protection)
  • Assumed all programs owned by the same person; but,
  • A problem in one program could bring down the whole machine.
  • Windows didn’t get standard OS stuff back until Windows 95
  • MacOS not until OS X.