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)