Soma at 15:27, 9 October 2018

2018-10-09T15:27:23Z

← Older revision		Revision as of 15:27, 9 October 2018
Line 2:		Line 2:

	I forgot to hit record so I don't have a recording of the session. If any of you recorded the audio please let me know and I will post it. Sorry!		I forgot to hit record so I don't have a recording of the session. If any of you recorded the audio please let me know and I will post it. Sorry!

			==Readings==

			See "man 4 urandom"

	==Notes from Lecture==		==Notes from Lecture==

Soma at 20:00, 5 October 2018

2018-10-05T20:00:04Z

← Older revision		Revision as of 20:00, 5 October 2018
Line 1:		Line 1:
	Note this lecture ~~will~~ not take place in our usual classroom; instead, go to ~~cuLearn~~ and ~~join~~ in ~~via~~ the ~~BigBlueButton link.~~		Note this lecture did not take place in our usual classroom; instead, it took place via BigBlueButton.

			I forgot to hit record so I don't have a recording of the session. If any of you recorded the audio please let me know and I will post it. Sorry!

			==Notes from Lecture==

			<pre>
			Lecture 10
			----------
			Topics
			- shared memory
			- format, questions on Test 1
			- Assignment 2 finalized, submissions open

			- randomness
			- /dev/random, /dev/urandom
			- interrupted system calls

			Randomness

			randomness versus pseudo-randomness

			pseudo-random
			- looks statistically random
			- but is generated by an algorithm
			- so, it is deterministic
			- to get different outputs, need a different "seed"


			Staticstical randomness is relatively easy
			has no relationship to predictability

			If you want hard to predict, you need a "cryptographically secure"
			pseudo-random number generator

			/dev/urandom - cryptographically secure pseudo-random number generator...
			seeded by /dev/random (or, the data behind it)

			/dev/random - source of "true" randomness

			ultimate source of randomness is physics
			- flipping a coin
			- radioactive decay
			- turbulent movement

			/dev/random is connected to device drivers
			- devices can have access to real randomness (physics phenomena)
			- examples
			- time for a hard drive head to settle down in a new position
			- inter-arrival times of network packets
			- CPUs have built-in "random number generators" based on
			physical phenomena
			- static on an audio device

			physical processes won't be unbiased - there will be a probability distribution

			So, what /dev/random does is
			- gathers events from different "random" sources
			- merges them together and processes them so you get a set
			of uniform random bits

			/dev/random is expensive in two ways
			- processing (whitening) costs some cycles
			- but most expensive is waiting for the events!



			Interrupted system calls

			this borders on a complex topic: scheduling

			How does the kernel switch between running processes?

			When a system call happens
			- process makes a system call
			- CPU switches to supervisor mode, jumps to system call handler
			- kernel processes system call
			- kernel switches CPU to user mode and sets up
			registers so process resumes where it left off
			(with results of system call in registers and the stack)

			Why does the kernel have to return to the same process that
			made the system call?
			- IT DOESN'T

			What about sleep?

			system call nanosleep just tells the kernel to wait for a while before
			running this process again

			Supervisor mode versus user mode

			Supervisor mode
			---------------
			- kernel code
			- entered by a
			- process making a system call
			- interrupt from a hardware device
			- runs on CPU directly with full privileges


			User mode
			---------
			- process code
			- entered by kernel running the process (switching from supervisor->user mode)
			- runs on CPU directly, but with limited privileges

			Could I run strace for ALL system calls on a system

			</pre>

			==Other Notes==

Soma: Created page with "Note this lecture will not take place in our usual classroom; instead, go to cuLearn and join in via the BigBlueButton link."

2018-10-02T21:33:56Z

Created page with "Note this lecture will not take place in our usual classroom; instead, go to cuLearn and join in via the BigBlueButton link."

New page

Note this lecture will not take place in our usual classroom; instead, go to cuLearn and join in via the BigBlueButton link.

Operating Systems 2018F Lecture 10 - Revision history

Soma at 15:27, 9 October 2018

Soma at 20:00, 5 October 2018

Soma: Created page with "Note this lecture will not take place in our usual classroom; instead, go to cuLearn and join in via the BigBlueButton link."