An operating system for a uniprocessor is some code loaded into main memory to handle hardware interrupts from devices and software interrupts (system calls) from user programs. (The Figure numbers below refer to Tanenbaum and Woodhull's book.) Why write this code? . for the user, this makes the machine more user friendly, i.e., extends the bare hardware into a virtual machine that has easier to use instructions (the system calls, Fig 1-16) . for the computer, to manage and allocate resources (CPUs, main memory, devices like tape drives, disk space, network) Onion layers view of a computing system user application software ---------------------------------------------------- system software (compilers, editors, etc.) ---------------------------------------------------- OS kernel (handles software and hardware interrupts) ---------------------------------------------------- hardware Categories of hardware and software interrupts CPU memory files network user raise, acquire, open, socket, system lower release read, connect, calls priority memory write listen, accept device round-robin first-fit directories, packets independent scheduling files of (management) logical blocks device context MMU disk controller dependent switching controller card (driver) commands commands interrupt clock fault, disk controller handlers parity controller card OS history . libraries of complicated device drivers . resident monitor to read card decks representing user jobs . hardware advances - multiprogramming: sharing IO and CPU, concurrent execution - memory protection - kernel mode - hardware clock - priviledged instructions: IO, halt, modify timer . distributed systems OS design structures . monolithic, Fig 1-17 . layered, Fig 1-18 . VM (virtual machine), Fig 1-19 . client-server e.g. MINIX and others, Fig 1-20 . distributed, Fig 1-21