Operating Systems 2019W Lecture 13

Video

The lecture given on March 4, 2019 is now available.

Notes

Lecture 13
----------

What's in an OS kernel?


What's a process?
 - "running program"
 - an instance of a virtual computer
   - virtual RAM  (must mmap or sbrk it, or started via execve)
   - virtual CPUs (get one, must clone for more threads)
   - I/O capabilities (system calls)

How do you make a thread?
 - clone
 - pthread

Kernel provides the infrastructure that enables processes

Key features
 - runs in supervisor mode on the CPU
   (processes run in user mode)


CPU modes:
  user mode - restricted access to system
  supervisor mode - full access to system resources

the kernel is just what you run in supervisor mode
processes run in user mode



How do I keep a kernel from crashing?
 - well, you can't
 - test a lot
 - formal verification (part or whole)


Linux is a monolithic kernel
 - everything's in there

But other OS kernels are "microkernels"
 - make as little as possible run in supervisor mode
 - less code -> less bugs
 - bugs in non-supervisor code has lower impact

What *has* to be in a kernel
 - enough to implement processes
   - including controlling access to hardware devices

 - code to create
   - virtual CPUs/execution contexts
   - memory maps
   - per-process (or other) access control to other devices


To make virtual CPUs, you just need a timer that interrupts programs
and returns control to the kernel (supervisor mode)
  - multiplexing over time
  - each process gets a "time slice"

"preemptive multitasking"

there exists in all modern CPUs clocks that can generate "interrupts"
 - an interrupt causes pre-specified supervisor code to run

Most I/O devices can generate interrupts
 - video cards
 - mass storage (HD/SSD)
 - networking interfaces
 - keyboard, mouse, etc

(If you don't have an interrupt, you must "poll" - CPU asks device periodically if it has any data)

Data can also go direct to and from memory via DMA (direct memory access)


For timer interrupts
--------------------

User space (CPU running in user mode)
 1. running a regular process
 5. another process runs (or the same process)


Kernel space (CPU running in supervisor mode)
 3. timer interrupt handler runs
    - keeps track of the time, updates counters
 4. run process scheduler, decide next process to run

Hardware
 2. timer interrupt goes off
 
clocks generate hardware interrupts
system calls generate software interrupts



For system calls
----------------

User space (CPU running in user mode)
 1. running a regular process
 2. regular process executed "syscall" instruction
 5. another process runs (or the same process)


Kernel space (CPU running in supervisor mode)
 3. syscall handler runs
    - figures out the system call
    - does the work of the syscall
 4. run process scheduler, decide next process to run

Hardware
 3. hardware notices special instruction, switches to supervisor
    mode and calls syscall "interrupt" handler


callbacks for I/O in node <=> blocked processes in a UNIX system


putting a process to sleep => remove from queue of processes getting CPU time

But what about RAM?
-------------------

You could just partition it
 - every process gets a different range of addresses
 - but what addresses do you use for variables and code?  They
   would change depending on where the process is loaded

Instead, use virtual addresses
 - on every memory access, translate virtual addresses to physical addresses
 - physical addresses are disjoint, virtual addresses can be the same
   between processes

What do you kick out of the kernel with a microkernel?
------------------------------------------------------
* device drivers
* filesystems
* networking stacks (TCP/IP)


Real-time operating systems
---------------------------
 - gives time-based guarantees for actions
   "deadlines"