Operating Systems 2015F Lecture 15 - Revision history

Soma: /* Video */

2015-11-06T20:09:12Z

Video

← Older revision		Revision as of 20:09, 6 November 2015
Line 1:		Line 1:
	==Video==		==Video==

			The video for the lecture given on November 4, 2015 [http://homeostasis.scs.carleton.ca/~soma/os-2015f/lectures/comp3000-2015f-lec15-04Nov2015.mp4 is now available].

	==Notes==		==Notes==

Soma: /* Notes */

2015-11-06T17:56:50Z

Notes

← Older revision		Revision as of 17:56, 6 November 2015
Line 10:		Line 10:
	* tell me war stories about bending the kernel to your will		* tell me war stories about bending the kernel to your will
	* tell be about the pain		* 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.		* 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		* it is fine to have some problems you haven't overcome

Line 50:		Line 51:

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


Line 67:		Line 70:
	- userspace => userspace		- userspace => userspace

	Switching contexts means saving register state, flushing caches, and loading a new register state		Switching contexts means saving register state, flushing caches, and loading
			a new register state

	Half a context switch is an upcall		Half a context switch is an upcall
Line 88:		Line 92:

	Monolithic versus microkernels		Monolithic versus microkernels
	- monolithic kernel: drivers, filesystems, network, memory management all run in supervisor mode		- monolithic kernel: drivers, filesystems, network, memory management all
	- microkernel: drivers, filesystem, network, and some memory management run in user mode (in processes)		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)		microkernels have to handle CPU and basic memory management
			(virtual memory mappings)

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

Soma: Created page with "==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 * specific..."

2015-11-06T17:55:35Z

Created page with "==Video== ==Notes== <pre> Lecture 15 My expectations for the oral interview * tell me war stories about bending the kernel to your will * tell be about the pain * specific..."

New page

==Video==

==Notes==

<pre>
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)
</pre>