Operating Systems 2015F Lecture 15

Video

The video for the lecture given on November 4, 2015 is now available.

Notes

Lecture 15

My expectations for the oral interview

* tell me war stories about bending the kernel to your will
* tell be about the pain
* specifically, you should be able to tell me about technical problems that
  you had to overcome to get code working in the kernel.
* it is fine to have some problems you haven't overcome


Flow of control in the kernel

the kernel as a web server

a web server
* waits for incoming web requests (HTTP GET, POST)
* dispatcher parses request and calls registered function for request
* when handler function returns, dispatcher handles next request


web servers have web clients

kernels have...
* processes (handles system calls for them)
* hardware (make requests, handle responses)
  - disks
  - video
  - keyboard
  - etc

   web server <--> web clients

   hardware <-->  kernel  <-->  processes

Similar because
  - have to handle many asynchronous requests
  - use *callbacks*

When the kernel boots, it registers callbacks with...
 THE CPU

 - the CPU has support for interrupts of various types
 - has a "trap table" for registering functions to handle those interrupts
 - kernel has to initialize the trap table

Why does this matter
 - in a web app, on the server you always code in terms of what URL was
   requested
 - in the kernel, always working in the context of a "request" from a
   process or hardware (or another part of the kernel)


What is the scheduler?
 - code that gets you back to userspace
 - you don't just "return from a function"
 - scheduler asks, "what do I do next?"


Context switch?

What is a context
  - execution context (process/thread)
    (CPU register state)
  - userspace => userspace
  
Switching contexts means saving register state, flushing caches, and loading
a new register state

Half a context switch is an upcall

upcall: go into the kernel

voluntary context switch: process/thread made a system call
involuntary context switch: hardware generated interrupt
  (timer, hard drive, whatever)

Threads versus processes
 - kernel deals is threads, not processes
   (called "tasks")
 - thread is an execution context
 - process is an execution context plus virtual memory
 - threads can share virtual memory (makes a multi-threaded process)
 - sharing virtual memory means sharing same virtual=>physical memory map
   (they share page tables)


Monolithic versus microkernels
 - monolithic kernel: drivers, filesystems, network, memory management all
   run in supervisor mode
 - microkernel: drivers, filesystem, network, and some memory management
   run in user mode (in processes)

microkernels have to handle CPU and basic memory management
(virtual memory mappings)

Why NOT run everything (or, as much as possible) as a process?


MacOS X and Windows (NT) started off as mostly pure microkernel designs
But...

MacOS needed UNIX compatibility
 - added in the FreeBSD kernel
 - technically, the FreeBSD kernel runs as a process...

So to make a system call on (old) MacOS X
 - process makes system call
 - Mach gets request, sends it to FreeBSD kernel
 - FreeBSD kernel handles request, sends it to Mach
 - Mach sends it back to the process

Note that you need double the number of context switches

You can optimize this using various techniques (e.g., shared memory)


Windows NT 3.51 had graphics running in a process
Windows NT 4 put it in the kernel.  For performance

Linux has support for kernel functionality in userspace
* FUSE, filesystems in userspace
  - NTFS is supported via a FUSE implementation
  - (version in the kernel is read only)