Video
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)