Operating Systems 2015F Lecture 2: Difference between revisions
|  Created page with "==Video==  ==Notes==" | No edit summary | ||
| (6 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| ==Video== | ==Video== | ||
| The video for this lecture [http://homeostasis.scs.carleton.ca/~soma/os-2015f/lectures/comp3000-2015f-lec02-09Sep2015.mp4 is now available].  Note that this lecture was pre-recorded. | |||
| ==Notes== | ==Notes== | ||
| Very abstract view of a computer: | |||
| [[File:Abstract-computer.svg]] | |||
| Flow of control for a system call: | |||
| [[File:Call-flow-process.svg]] | |||
| '''Key Questions:''' | |||
| * What is a system call, really? | |||
| * How are programs separated from each other? | |||
| * What is this "scheduler" anyway? | |||
| System calls are the interface between a process and the operating system kernel.  They are like function calls, but they are not function calls (although they may be wrapped in library function calls). | |||
| Classic system calls: | |||
| * files: open, read, write, close | |||
| * process control: fork, execve, exit | |||
| * memory: sbrk | |||
| * networking (socket calls) | |||
| Key idea: CPU privilege levels | |||
| * applications run in "user mode", lowest level of privileges | |||
| ** no direct access to I/O devices | |||
| ** no ability to change amount of RAM | |||
| ** cannot control how often it has the CPU | |||
| * Operating system runs at higher privilege | |||
| ** gets privileges because it runs first (at boot) | |||
| ** specifically, the OS kernel runs in "supervisor mode" | |||
| ** can control CPU, RAM, and I/O devices | |||
| ** kernel maintains control by setting interrupt registers (will explain more later) | |||
| So why isn't a system call a function call? | |||
| * function calls involve references to specific memory locations | |||
| * processes cannot directly see kernel memory | |||
| So what does an application do instead to make a system call? | |||
| * executes a special CPU instruction (software interrupt) | |||
| * cannot be done outside of assembly language without special support from the compiler | |||
| Concepts that I think are unclear: | |||
| * mounting | |||
| * strace | |||
| * system calls | |||
Latest revision as of 21:38, 8 September 2015
Video
The video for this lecture is now available. Note that this lecture was pre-recorded.
Notes
Very abstract view of a computer:
Flow of control for a system call:
Key Questions:
- What is a system call, really?
- How are programs separated from each other?
- What is this "scheduler" anyway?
System calls are the interface between a process and the operating system kernel. They are like function calls, but they are not function calls (although they may be wrapped in library function calls).
Classic system calls:
- files: open, read, write, close
- process control: fork, execve, exit
- memory: sbrk
- networking (socket calls)
Key idea: CPU privilege levels
- applications run in "user mode", lowest level of privileges
- no direct access to I/O devices
- no ability to change amount of RAM
- cannot control how often it has the CPU
 
- Operating system runs at higher privilege
- gets privileges because it runs first (at boot)
- specifically, the OS kernel runs in "supervisor mode"
- can control CPU, RAM, and I/O devices
- kernel maintains control by setting interrupt registers (will explain more later)
 
So why isn't a system call a function call?
- function calls involve references to specific memory locations
- processes cannot directly see kernel memory
So what does an application do instead to make a system call?
- executes a special CPU instruction (software interrupt)
- cannot be done outside of assembly language without special support from the compiler
Concepts that I think are unclear:
- mounting
- strace
- system calls

