Content is from the course ECE350 at the University of Waterloo. Eventually I will clean it up with proper citations.
Main textbook: [1]
Suggested reading:
Roles of the OS
The OS is an illusionist. It provides a clean abstraction of physical resources to processes (infinite memory, dedicated machine). It also provides higher-level objects like files, users, and messages.
The ISA (instruction set architecture) is a contract between the hardware vendor and OS developers. It defines the interface between the hardware and the OS to faciliate further abstraction.
The OS is a referee. Processes are competing for the same resources. Especially for a general purpose OS, the developers of applications are not the same as the developers of the OS. The OS must protect and isolate the running environment of individual processes. It must further facilitate communication between processes.
The OS is the common glue. It provides common services to all processes. More generally, the OS may also provide a common “look and feel.”
Log
Day 2
one job at a time (serialized) became Batch System (monitor) because utilization was better.
- Monitor controls sequence of events (batching jobs together)
- Program returns control to monitor when finished.
- Improved utilization
Next step: I need monitor to keep running while jobs are running. Let’s put monitor in one portion of memory and memory for one job at a time in other part, with a boundary.
| Interrupt processing | only way to regain monitor ctrl if job running
| Device driver |
| Job sequencing | logic to run jobs one after another
| Control language interpreter | FORTRAN interp.
| ---------------------------- BOUNDARY
| (User program area) |- Problem: erroneous job corrupts entire system by overwriting monitor memory.
- Need new HW features
- Memory protection: memory containing monitor cannot be altered by jobs
- Timer (primitive interrupt): timer interrupts user jobs after a time to return control to the monitor
- Privileged instructions: I/O instructions only executed by monitor
- So HW can know if its running a job (user mode) or the monitor (kernel mode), distinguish between modes of operation.
- Done by adding register in processor that keeps track of the current mode.
- Shortcoming of batch system: I/O still slow. A job waiting for I/O would slow down all other jobs and processor would be idle. (Uniprogramming)
- Solution: Multiprogramming. When one job is waiting for I/O, switch to the other job.
- Requires memory management to keep track of which job is in which memory location. Virtual memory and paging.
- To switch between jobs, need I/O interrupts (tell A that their IO is finished) and DMA I/O (move transfer to memory first). Processor can’t be polling during I/O.
- Time-sharing systems: add an additional user abstraction so that many people can run jobs “at the same time,” attaching multiple terminals to one mainframe.
- Interactive I/O for user inputs (requires fair scheduling for keyboard inputs)
Day 1
- Filesystems are like key-value stores.
- Virtual memory and address spaces are hard.
- ECE320 (architecture) teaches consistency and cache-coherence.
- Computer engineers improved efficiency initially by throwing more cores at the problem.
- Adding multiple cores and parallelism makes everything harder.
- We will spend significant time on the case of multiple-core synchronization.
- The HW supports most operating system activities.
- HW is co-evolving with the software (they are mutually developed to meet each others’ requirements)
- For example, HW supports virtual memories (translation interface, page tables) and atomic operations (get/set)
- We will use ARMv7 ISA and the Cortex-M processor for examples.
- Switching into kernel mode, the procedure is different even though the ISA is the same.
- We won’t be asked to implement virtual memory.
- We will be asked to implement dynamic memory allocation, as done by the kernel for
malloc/kmalloc. - We will also be asked to implement a real-time scheduler.
- Hypervisors are cool! (more research needed)
- Hardware accelerators are an example of when OS enables access to specialized hardware through device drivers.
- We should know: ECE222 (computer organization, interrupts, ARMv7 ISA, addressing modes, hardware cache miss types and replacement algos)
- Know: how does subroutine linkage work? We will examine the stack frame for a related case of the system call (similar but separate procedure)
- Hardware versus software cache and various replacement algos.
- We should know: ECE252 (system call sequence and terminology, traps, mode change, SVC, atomic transactions from users’ perspective, IPC)
- We will examine kernel implementations of system calls, semaphore, monitor, a file system API.
Labs:
- Multiprogramming: implement OS with context-switching between tasks. The processes will have no memory protection (because basic memory protection is trivial while virtual memory is hard)
A “task” refer to a scheduling entity for the OS, but we can interpret them as processes. For example, the Linux kernel uses a “task struct” to store information about separate entities to be scheduled, which may be threads or processes.
- Dynamic memory allocation
- Scheduling (real-time earliest-deadline first algorithm)
What is OS?
- “Everything that vendors ship when you order OS” is good approximation
- What is present is always the kernel
For us:
- OS is layer of software that abstracts access to hardware.
- Provides protected access to shared resources (access control)
- Enables IPC between processes
Roles of the OS (see section)