rtc: Fix Unix epoch conversion from RTC time.

[pintos-anon] / doc / threads.texi

diff --git a/doc/threads.texi b/doc/threads.texi
index b13b5450ff00802e06fa346894a6955ece891f4e..c9094bc2d073ddd5642aad218fc82465ecabdc5c 100644 (file)
--- a/doc/threads.texi
+++ b/doc/threads.texi
@@ -113,27 +113,30 @@ code to look at.
 @item loader.S
 @itemx loader.h
 The kernel loader.  Assembles to 512 bytes of code and data that the
-PC BIOS loads into memory and which in turn loads the kernel into
-memory, does basic processor initialization, and jumps to the
-beginning of the kernel.  @xref{Pintos Loader}, for details. You should
-not need to look at this code or modify it.
+PC BIOS loads into memory and which in turn finds the kernel on disk,
+loads it into memory, and jumps to @func{start} in @file{start.S}.
+@xref{Pintos Loader}, for details.  You should not need to look at
+this code or modify it.
+
+@item start.S
+Does basic setup needed for memory protection and 32-bit
+operation on 80@var{x}86 CPUs.  Unlike the loader, this code is
+actually part of the kernel.  @xref{Low-Level Kernel Initialization},
+for details.
 
 @item kernel.lds.S
 The linker script used to link the kernel.  Sets the load address of
-the kernel and arranges for @file{start.S} to be at the very beginning
+the kernel and arranges for @file{start.S} to be near the beginning
 of the kernel image.  @xref{Pintos Loader}, for details. Again, you
 should not need to look at this code
 or modify it, but it's here in case you're curious.
 
-@item start.S
-Jumps to @func{main}.
-
 @item init.c
 @itemx init.h
 Kernel initialization, including @func{main}, the kernel's ``main
 program.''  You should look over @func{main} at least to see what
 gets initialized.  You might want to add your own initialization code
-here.  @xref{Kernel Initialization}, for details.
+here.  @xref{High-Level Kernel Initialization}, for details.
 
 @item thread.c
 @itemx thread.h
@@ -220,10 +223,23 @@ Serial port driver.  Again, @func{printf} calls this code for you,
 so you don't need to do so yourself.
 It handles serial input by passing it to the input layer (see below).
 
-@item disk.c
-@itemx disk.h
-Supports reading and writing sectors on up to 4 IDE disks.  This won't
-actually be used until project 2.
+@item block.c
+@itemx block.h
+An abstraction layer for @dfn{block devices}, that is, random-access,
+disk-like devices that are organized as arrays of fixed-size blocks.
+Out of the box, Pintos supports two types of block devices: IDE disks
+and partitions.  Block devices, regardless of type, won't actually be
+used until project 2.
+
+@item ide.c
+@itemx ide.h
+Supports reading and writing sectors on up to 4 IDE disks.
+
+@item partition.c
+@itemx partition.h
+Understands the structure of partitions on disks, allowing a single
+disk to be carved up into multiple regions (partitions) for
+independent use.
 
 @item kbd.c
 @itemx kbd.h
@@ -246,6 +262,16 @@ and serial drivers.
 Real-time clock driver, to enable the kernel to determine the current
 date and time.  By default, this is only used by @file{thread/init.c}
 to choose an initial seed for the random number generator.
+
+@item speaker.c
+@itemx speaker.h
+Driver that can produce tones on the PC speaker.
+
+@item pit.c
+@itemx pit.h
+Code to configure the 8254 Programmable Interrupt Timer.  This code is
+used by both @file{devices/timer.c} and @file{devices/speaker.c}
+because each device uses one of the PIT's output channel.
 @end table
 
 @node lib files
@@ -617,6 +643,18 @@ to cause many of the tests to fail.
 
 @xref{Testing}.
 
+@item Should I try running the tests with jitter?
+
+Using the jitter feature in Bochs (@pxref{Debugging versus Testing})
+is a great way to discover bugs that are timing dependent. However,
+the following tests are known to
+fail with jitter even if your code is correct: @code{alarm-priority},
+@code{alarm-simultaneous},
+@code{mlfqs-recent-1}, @code{mlfqs-fair-2}, @code{mlfqs-fair-20},
+@code{mlfqs-nice-2}, @code{mlfqs-nice-10}, and @code{priority-fifo}.
+The behavior of these tests can sometimes vary based on timing (e.g.,
+if a timer interrupt arrives at an inconvenient time).
+
 @item Why do I get a test failure in @func{pass}?
 
 @anchor{The pass function fails}
@@ -700,7 +738,7 @@ kernel thread but the first.
 Don't worry about the possibility of timer values overflowing.  Timer
 values are expressed as signed 64-bit numbers, which at 100 ticks per
 second should be good for almost 2,924,712,087 years.  By then, we
-expect Pintos to have been phased out of the @value{coursenumber} curriculum.
+expect Pintos to have been phased out of the Computer Science curriculum.
 @end table
 
 @node Priority Scheduling FAQ