2 Attention
Week 2: September 5 - 9, 2022
- DINOS 3.1, 2.3, 12.2.3
- LOVE pgs (Chapter 5) 69-73.5, (Chapter 7, 8) 113-115, 122, 133-135
This module is about getting the attention of the kernel either from a currently executing user-process through system calls or from hardware through interrupts.
The use of indirection – tables that map codes to system-call or interrupt handlers – is a commonly recurring theme in operating system design. This design gives us lots of flexibility in terms of our ability to design with a possibility of expanding our features (i.e. system calls we can support or hardware interrupts we can service) in the future.
We first build some initial intuition about what a process is: leaving many of the details of what makes the state of a process, how is it managed, scheduled, etc, for later lectures. And, then recognize that a processor can be in one of several contexts depending on whether a user-process is executing, kernel code is executing or an interrupt handler. Each of these contexts determine to a certain degree what privileges are available.
When learning about system calls, it is important to recognize that a user-space application can’t just execute kernel code directly.
For one, kernel code exists in a protected memory space and if the application can directly read or write to kernel address space, then security is practically non-existent. The system call is a mechanism to switch to kernel mode so that the system call can be executed in kernel space on behalf of the process. Note that the x86 microprocessors can support multiple execution states or modes, ut all standard Unix kernels use only Kernel Mode and User Mode. Each CPU model provides special instructions to switch from User Mode to Kernel Mode and vice versa. A program usually executes in User Mode and switches to Kernel Mode only when requesting a service provided by the kernel. When the kernel has satisfied the program’s request, it puts the program back in User Mode.
#When a program is executed in User Mode, it cannot directly access the kernel data structures or the kernel programs. When an application executes in Kernel Mode, however, these restrictions no longer apply. Each CPU model provides special instructions to switch from User Mode to Kernel Mode and vice versa. A program usually executes in User Mode and switches to Kernel Mode only when requesting a service provided by the kernel. When the kernel has satisfied the program’s request, it puts the program back in User Mode. #Processes are dynamic entities that usually have a limited life span within the sys- tem. The task of creating, eliminating, and synchronizing the existing processes is delegated to a group of routines in the kernel.
The kernel itself is not a process but a process manager.
#The process/kernel model assumes that processes that require a kernel service use specific programming con- structs called system calls. Each system call sets up the group of parameters that identifies the process request and then executes the hardware-dependent CPU instruction to switch from User Mode to Kernel Mode.
What are some examples of system calls?
- Process control: e.g. create, terminate, load, get or set process attributes, wait/sleep (fork(), exec(), getpid())
- File management: create, open, delete, close, read, write, get/set file attributes
- Device management: read, write, mount, …
- Information: time, date, get or set this system data, …
- Communication: pipes, send, receive, …
- Protection: get or set permissions, …
2.1 A video summary
2.1.2 Interrupt Handling & Top/Bottom Halves
Learning Objectives
Process
- What is a process?
- What abstractions does it provide?
- How is it different from a program or an executable?
System Calls vs. Interrupts
- In x86, what does the INT instruction do?
- Why do we need system calls?
- Why should the kernel mediate hardware access from user processes? Are there situations where a user process can directly access hardware?
- What is the difference between a system call, an exception and an interrupt?
- Why can’t an interrupt handler sleep?
- Why does Linux split interrupt processing into a top-half and a bottom half?