Operating systems

Lesson 1 of 81961–today7 min

What an operating system does

In November 1961 Fernando Corbató's group at MIT demonstrated a crude prototype of the Compatible Time-Sharing System on an IBM 709: four users at typewriter terminals, sharing one computer at the same time, each working as if the machine were theirs. Until then a computer ran one job at a time, and programmers queued with their card decks.

The trick was a supervisor program that sat between the users and the machine, handed the processor to each in turn and kept their work apart. Every operating system since does those same two jobs.

Two jobs: illusionist and referee

An operating system first builds abstractions that hide the hardware: a process looks like a private computer, virtual memory looks like a large private address space, a file looks like a named sequence of bytes instead of scattered disk blocks. Then it acts as referee: it shares the CPU, memory and devices among programs that do not trust each other, and it stops any of them from reading another's data or taking over the machine. The part that runs with full privilege to do this is the kernel. The shell, the desktop, compilers and utilities are ordinary programs that run on top of it.

User mode and kernel mode

The referee only works if the hardware backs it. Every modern CPU has at least two privilege levels: x86 calls them rings (the kernel runs in ring 0, applications in ring 3), ARM calls them exception levels (EL0 for applications, EL1 for the kernel). Some instructions are privileged: talking to devices, changing the page tables, disabling interrupts, halting the processor. If a program in user mode tries one, the CPU refuses and raises an exception that hands control to the kernel. There are three ways into the kernel: a system call, which is a deliberate trap; an exception, caused by the running instruction (a page fault, a division by zero); and an interrupt, raised by a device or by the timer. The timer interrupt matters most: it is how the kernel takes the CPU back from a program that never gives it up.

One write() call, from program to kernel and backStep 1 of 5
Program
C library
CPU
Kernel

Program → C library: write(1, msg, 14)

An ordinary function call in user mode.
c
#include <string.h>
#include <unistd.h>

int main(void) {
    const char *msg = "hello, kernel\n";
    /* write() is a thin wrapper: the C library loads the
       call number and arguments into registers and traps. */
    ssize_t n = write(1, msg, strlen(msg));  /* fd 1 = stdout */
    return n < 0 ? 1 : 0;
}
The smallest useful system call. On Linux, strace ./hello lists every call the program makes.

Worked exercise

Privileged or not?

A program runs in user mode on x86-64 Linux. For each operation, say whether it executes directly or how it gets done: (a) add two registers; (b) read 4 KiB from a file on disk; (c) execute cli to disable interrupts; (d) divide an integer by zero; (e) load a new page-table base into register CR3.

Try it first, then reveal the solution one step at a time.

Key terms

Kernel
The part of the OS that runs in privileged mode and manages CPU, memory and devices.
User mode
The CPU's restricted level: privileged instructions raise an exception instead of running.
System call
A deliberate trap through which a program asks the kernel to do something on its behalf.
Interrupt
A signal from a device or timer that makes the CPU suspend what it runs and enter the kernel.
Exception
A trap caused by the current instruction, such as a page fault or a division by zero.

Check what you learned

  1. 1.Why does the kernel program a periodic timer interrupt?

  2. 2.Which of these events is a system call?

  3. 3.In x86 terminology, where do the kernel and ordinary applications run?

Practise it for the exam

Sources