Merge branch 'master' of github.com:ops-class/www

src/slides/2016/filesystemstructures.adoc

@@ -119,7 +119,7 @@ block.
 == Data Blocks: Flat Array
 
 A second solution: store all data blocks in the inode in a single
-array allocate at file creation time.
+array allocated at file creation time.
 
 [.slider]
 .Pros:

src/slides/2016/forksynch.adoc

@@ -183,7 +183,7 @@ if (returnCode == 0) {
 
   # Read some data from the pipe.
   char data[14];
-  read(pipeEnds[0], data, 16);
+  read(pipeEnds[0], data, 14);
 } else {
 
   # Don't need a loopback.
@@ -264,7 +264,7 @@ later.
 
 [.slider]
 .The *operating system* itself is one of the most difficult concurrent programs to write. Why?
-* It is multiplexing access to hardware resources and therefor sharing
+* It is multiplexing access to hardware resources and therefore sharing
 a great deal of state between multiple processes!
 * It frequently uses many threads to hide hardware delays while
 servicing devices and application requests.

src/slides/2016/pagetranslation.adoc

@@ -206,7 +206,7 @@ effective.
 
 [.slider]
 * 4K is a very common page size. 8K or larger pages are also sometimes used.
-* 4K pages and a 128-entry TLB allow caching translations for 1 MB of
+* 4K pages and a 128-entry TLB allow caching translations for 512 KB of
 memory.
 * You can think of pages as *fixed size* segments, so the *bound* is the
 same for each.

src/slides/2016/processes.adoc

@@ -233,7 +233,7 @@ received.
 send a signal to any process.
 * Processes can ignore most signals.
 ** `SIGKILL` is a notable exception; used for non-graceful termination.
-** `SIGTERM` is used for graceful shutdown and sent by Control-C.
+** `SIGTERM` is used for graceful shutdown.
 
 == !
 

src/slides/2016/schedulingstory.adoc

@@ -409,7 +409,7 @@ ____
 * Priority defines the levels at which each task can run.
 ** High priority tasks: *more* levels, *more* chances to run.
 ** Low priority tasks: *fewer* levels, *fewer* chances to run.
-* Tasks can run more at most a fixed amount of time per level.
+* Tasks can run for at most a fixed amount of time per level.
 * Each level can also run for at most a fixed amount of time--ensures *bounded
 latency*.
 

src/slides/2016/synchprimitives.adoc

@@ -338,12 +338,12 @@ has not changed since the load-link.
 ----
 y = 1;
 __asm volatile(
-    ".set push;"    /* save assembler mode */
-    ".set mips32;"  /* allow MIPS32 instructions */
-    ".set volatile; /* avoid unwanted optimization */
-    "ll %0, 0(%2);" /*   x = *sd */
-    "sc %1, 0(%2);" /*   *sd = y; y = success? */
-    ".set pop"      /* restore assembler mode */
+    ".set push;"     /* save assembler mode */
+    ".set mips32;"   /* allow MIPS32 instructions */
+    ".set volatile;" /* avoid unwanted optimization */
+    "ll %0, 0(%2);"  /*   x = *sd */
+    "sc %1, 0(%2);"  /*   *sd = y; y = success? */
+    ".set pop"       /* restore assembler mode */
     : "=r" (x), "+r" (y) : "r" (sd));
 if (y == 0) {
   return 1;

src/slides/2016/synchproblems.adoc

@@ -175,7 +175,7 @@ image::figures/synch/spinlocks.svg[width="70%"]
 == How to Sleep
 
 [.slider]
-.The kernel provide functionality allowing kernel threads to sleep and wake on a *key*:
+.The kernel provides functionality allowing kernel threads to sleep and wake on a *key*:
 * `thread_sleep(key)`: "Hey kernel, I'm going to sleep, but please wake
 me up when *`key`* happens."
 * `thread_wake(key)`: "Hey kernel, please wake up all (or one of) the
@@ -224,7 +224,7 @@ withdraw items.
 
 [.slider]
 .Why are condition variables a synchronization mechanism?
-* Want to ensure that the condition *does not change* between checking it and
+* Want to ensure that the condition *does not change* between checking it
 and deciding to wait!
 
 [cols="2*",options='header',role='slide']

src/slides/filesystemstructures.adoc

@@ -54,10 +54,6 @@ and delete (`dtime`) times.
 
 image::figures/disks/debugfs-stat.svg[width="100%"]
 
-== `ext4` inodes
-
-image::figures/disks/debugfs-stat.svg[width="100%"]
-
 == Locating inodes
 
 [.slider]
@@ -144,7 +140,7 @@ block.
 == Data Blocks: Flat Array
 
 A second solution: store all data blocks in the inode in a single
-array allocate at file creation time.
+array allocated at file creation time.
 
 [.slider]
 .Pros:

src/slides/forksynch.adoc

@@ -264,7 +264,7 @@ if (returnCode == 0) {
 
   # Read some data from the pipe.
   char data[14];
-  read(pipeEnds[0], data, 16);
+  read(pipeEnds[0], data, 14);
 } else {
 
   # Don't need a loopback.

src/slides/moreprocesses.adoc

@@ -107,7 +107,7 @@ received.
 send a signal to any process.
 * Processes can ignore most signals.
 ** `SIGKILL` is a notable exception; used for non-graceful termination.
-** `SIGTERM` is used for graceful shutdown and sent by Control-C.
+** `SIGTERM` is used for graceful shutdown.
 
 == !
 
@@ -129,7 +129,7 @@ spaces and virtual memory.
 == Processes v. Threads
 
 [.small.slider]
-* Potential confusing due to overlapping terminology--we can describe
+* Potentially confusing due to overlapping terminology--we can describe
 both a *process* and a *thread* as running.
 * Terminology can be helpful for remembering the distinction:
 ** A computing *process* requires multiple resources: the CPU, memory,

src/slides/processes.adoc

@@ -210,7 +210,7 @@ other.
 
 [.slider]
 * What you do in your own process is your own business *but it shouldn't
-be able to crash the machine or effect other processes*—or at least
+be able to crash the machine or affect other processes*—or at least
 processes started by other users.
 * Thus: safe intra-process communication is *your* problem; safe
 inter-process communication is an *operating system* problem.

src/slides/schedulingstory.adoc

@@ -347,7 +347,7 @@ ____
 * Priority defines the levels at which each task can run.
 ** High priority tasks: *more* levels, *more* chances to run.
 ** Low priority tasks: *fewer* levels, *fewer* chances to run.
-* Tasks can run more at most a fixed amount of time per level.
+* Tasks can run for at most a fixed amount of time per level.
 * Each level can also run for at most a fixed amount of time--ensures *bounded
 latency*.
 

src/slides/synchprimitives.adoc

@@ -88,7 +88,7 @@ later.
 
 [.slider]
 .The *operating system* itself is one of the most difficult concurrent programs to write. Why?
-* It is multiplexing access to hardware resources and therefor sharing
+* It is multiplexing access to hardware resources and therefore sharing
 a great deal of state between multiple processes!
 * It frequently uses many threads to hide hardware delays while
 servicing devices and application requests.

src/slides/synchproblems.adoc

@@ -121,12 +121,12 @@ has not changed since the load-link.
 ----
 y = 1;
 __asm volatile(
-    ".set push;"    /* save assembler mode */
-    ".set mips32;"  /* allow MIPS32 instructions */
-    ".set volatile; /* avoid unwanted optimization */
-    "ll %0, 0(%2);" /*   x = *sd */
-    "sc %1, 0(%2);" /*   *sd = y; y = success? */
-    ".set pop"      /* restore assembler mode */
+    ".set push;"     /* save assembler mode */
+    ".set mips32;"   /* allow MIPS32 instructions */
+    ".set volatile;" /* avoid unwanted optimization */
+    "ll %0, 0(%2);"  /*   x = *sd */
+    "sc %1, 0(%2);"  /*   *sd = y; y = success? */
+    ".set pop"       /* restore assembler mode */
     : "=r" (x), "+r" (y) : "r" (sd));
 if (y == 0) {
   return 1;
@@ -426,7 +426,7 @@ image::figures/synch/spinlocks.svg[width="70%"]
 == How to Sleep
 
 [.slider]
-.The kernel provide functionality allowing kernel threads to sleep and wake on a *key*:
+.The kernel provides functionality allowing kernel threads to sleep and wake on a *key*:
 * `thread_sleep(key)`: "Hey kernel, I'm going to sleep, but please wake
 me up when *`key`* happens."
 * `thread_wake(key)`: "Hey kernel, please wake up all (or one of) the
@@ -475,7 +475,7 @@ withdraw items.
 
 [.slider]
 .Why are condition variables a synchronization mechanism?
-* Want to ensure that the condition *does not change* between checking it and
+* Want to ensure that the condition *does not change* between checking it
 and deciding to wait!
 
 [cols="2*",options='header',role='slide']