CSE 451

Operating Systems

L1 - OS Overview

Slides by: Tom Anderson

Baris Kasikci

Course Staff

Instructors: Baris Kasikci and Rohan Kadekodi

• Prof. Baris Kasikci (Prof. K.), Prof. Baris (Prof. Barish), Prof. BK
• Dr. Rohan Kadekodi

TAs:

Jonathan Trinh (Head TA)

Yusong Yan

Druhin Bhowal

Zack Crouse

Soham Raut

Abhay Nori

Tim Avilov

How This Course Fits in the UW CSE Curriculum

• CSE 333: Systems Programming
• Project experience in C/C++
• How to use the operating system interface
• CSE 451: Operating Systems
• How to make a single computer work reliably and securely
• How an operating system works internally
• CSE 452: Distributed Systems
• How to make a set of computers work reliably, despite failures of some nodes
• CSE 453: Data Center Systems
• How to manage a very large number of computers as a shared resource
• CSE 454: Machine Learning Systems (soon)
• How does modern training & inference infrastructure work?

Course Project: xk

• Build an operating system
• That can boot on a real system
• Run multiple processes
• Support extensible virtual memory
• Store file data reliably
• We give you some basic starting code
• Four assignments, that build on each other
• Work in groups of 2
• Group formation form
• Instructions on web page
• Download and browse code before section
• Bring laptop or smartphone to section

Grading

• Grade breakdown
• 40% Labs/Lab Questions
• 15% Problem Sets
• 5% Design Docs
• 15% Midterm
• 25% Final (6/10/2026 @ 2:30 pm)
• Need a passing grade from exams to pass
• If the lowest exam average is > 50 (2/4*100), this rule doesn’t apply
• Understanding the labs is essential to getting a passing grade from exams

​

Academic Honesty

Do not:

​

• Share code or written solutions
• Use others' solutions
• Use AI tools to write code or solutions

​

Design Docs:

​

• Irrelevant content -> 0 & no feedback
• E.g., AI-generated

​

​

Main Points (for today)

• Operating system definition
• Software to manage a computer’s resources for its users and applications
• Why is OS programming hard
• Reliability, security, responsiveness, portability, …
• OS history
• How did we get here?
• Computer hardware from the OS perspective
• Different from how applications see hardware (CSE 351)
• How I/O works

What is an operating system?

• Software to manage a computer’s resources for its users and applications
• For any area of an OS (CPU, memory, storage, network):
• What is the hardware interface?
• What is the application interface?
• App appears to have the entire machine to itself (isolation)
• Bug in one app doesn’t crash your app
• Malicious user can’t access your data

OS

Operating System Roles

• Referee:
• Isolation of different users, applications from each other
• Resource allocation among users, applications when there is contention
• Communication between users, applications (pipes, shared memory, files)
• Illusionist
• Each application appears to have the entire machine to itself, without limitation
• Infinite number of processors, (near) infinite amount of memory, reliable storage,

reliable network transport

• Glue
• Libraries, user interface widgets, …

Example: File Systems

• Referee
• Prevent users from accessing each other’s files without permission
• Even after a file is deleted and its space re-used
• Illusionist
• Files can grow (nearly) arbitrarily large
• Files persist even when the machine crashes in the middle of a save
• Glue
• Named directories, printf, …

Many Other Systems Apply OS Principles

• Web browsers: web pages embed programs
• how do we isolate these programs from one another?
• How do we protect the browser from attacks launched by these programs?
• Data centers: millions of CPUs, disks
• Shared resources at the large scale; how do we arbitrate contention?
• How do we isolate different users from one another, even if some are malicious?
• Cloud services (eg, Amazon’s elastic block store)
• How do we ensure no user monopolizes service or steals other user data?
• Databases: shared data for many different users
• How do we keep data from different users private?
• AI infrastructure
• Training and serving systems: how do we efficiently orchestrate training and inference systems?

Why is OS Programming Hard?

• Adversarial users
• Every application is a potential source of attack
• Can use entire capability of machine to launch attack
• OS code needs to be perfect
• Bug in one application affects that application
• Bug in kernel affects all applications
• Security bug in kernel compromises all user data
• Often performance critical, especially for cloud apps
• Abstraction mismatch
• OS provides convenient abstractions to applications
• OS can’t use those abstractions (what if app causes kernel to run out of memory?)

Computer Performance Over Time

OS History

Relative cost of computing vs. people using them

• Early computers: computers very expensive
• Batch systems: keep CPU busy by having long list of tasks to run
• Users would submit jobs, and wait, and wait, and wait, …
• Time shared computers: both people and computers expensive
• Multiple users per computer; multiple programs running at same time
• Interactive performance: try to complete tasks quickly
• Personal computers and smartphones: computers cheap, people expensive
• One user per computer; computer spends most of its time idle
• Developer speed paramount -> how fast can you add features users want
• Cloud and data center computing
• Efficient use of shared computing resources (cloud infra is $40/human/year in 2024)

What is a computer?

Physical Address Layout

• What happens when computer powers up?
• How does OS kernel get loaded into memory?
• BIOS contains CPU instructions
• OS kernel and applications share memory
• how do we prevent apps from modifying

kernel data (or data in other apps)

• I/O device controllers addressed as memory
• CPU sends commands to I/O device through memory reads/writes
• how do we prevent apps from issuing commands to read or modify disk blocks owned by other apps/users?

load r1, <address>

bootloader

OS

Device I/O

• OS kernel needs to communicate with physical devices
• Network, disk, video, USB, keyboard, mouse, …
• Devices operate asynchronously from the CPU
• Each with their own microprocessor controller
• How does the OS communicate with the controller?
• I/O devices assigned a range of memory addresses, separate from main DRAM
• CPU read/write memory locations to issue commands/read results
• How does CPU make use of the time while waiting for I/O to finish?

Synchronous vs. Asynchronous I/O

• Synchronous I/O: Polling
• OS pokes I/O memory on device to issue request
• While device is working, kernel polls I/O memory to wait until I/O is done
• Device completes, stores data in its buffers
• Kernel copies data from device into memory
• Asynchronous: Interrupts
• OS pokes I/O memory on device to issue request; CPU goes back to work on some

other task

• Device completes, stores data in its buffers
• Triggers CPU interrupt to signal I/O completion
• OS runs device specific handler; when done, resume previous work

Faster I/O: DMA and Buffer Descriptors

• Direct memory access (DMA)
• I/O device directly reads/writes computer’s memory (ex: incoming network packet

stored directly in DRAM)

• Buffer descriptor: data structure to specify where to find the I/O request
• E.g., packet header and packet body
• Buffer descriptor itself is DMA’ed!
• CPU and device I/O share a queue of buffer descriptors
• I/O device reads from front
• CPU fills at tail
• Interrupt only if buffer empties/fills

Buffer Descriptors Illustrated

Device Interrupts

• How do device interrupts work?
• Where does the CPU run after an interrupt?
• What is the interrupt handler written in? C? Java?
• What stack does it use?
• Is the work the CPU had been doing before the interrupt lost forever?
• If not, how does the CPU know how to resume that work?

Interrupt Vector

• Table set up by OS kernel; points to code to run on different events

Interrupt Vector on x86

Interrupt Masking

• Interrupt handler runs with interrupts off
• Re-enabled when interrupt completes
• OS kernel can also turn interrupts off
• Eg., when determining the next process/thread to run
• On x86
• CLI: disable interrrupts
• STI: enable interrupts
• Only applies to the current CPU (on a multicore)
• We’ll need this to implement context switching

Challenge: Saving/Restoring State

• Efficient I/O requires us to be able to run something else while the I/O operation is ongoing
• Device copies its data directly into/out of memory (DMA, buffer descriptors)
• Hardware CPU interrupt signals completion
• Thus, we need to be able to interrupt and transparently resume execution of the background task
• Code must be unaware it has been interrupted!
• Need to restore not just the program counter, but also all other parts of the CPU

state - condition codes, registers, …