Ignore more files.

[pintos-anon] / doc / threads.texi

diff --git a/doc/threads.texi b/doc/threads.texi
index fbd8ac33e5c751add91b795952ffeb308fc46a79..451eff8ee2cc73bff7901efe24d077aba5a2d021 100644 (file)
--- a/doc/threads.texi
+++ b/doc/threads.texi
@@ -135,10 +135,6 @@ above.
 @itemx palloc.h
 Page allocator, which hands out system memory one 4 kB page at a time.
 
-@item paging.c
-@itemx paging.h
-Initializes the kernel page table.  FIXME
-
 @item malloc.c
 @itemx malloc.h
 A very simple implementation of @code{malloc()} and @code{free()} for
@@ -205,16 +201,14 @@ thread switches.  That means that running the same test several times
 doesn't give you any greater confidence in your code's correctness
 than does running it only once.
 
-FIXME
 So, to make your code easier to test, we've added a feature to Bochs
 that makes timer interrupts come at random intervals, but in a
-perfectly predictable way.  In particular, if you put a line
-@samp{ips-jitter: @var{seed}}, where @var{seed} is an integer, into
-your Bochs configuration file, then timer interrupts will come at
-irregularly spaced intervals.  Within a single @var{seed} value,
-execution will still be reproducible, but timer behavior will change
-as @var{seed} is varied.  Thus, for the highest degree of confidence
-you should test your code with many seed values.
+perfectly predictable way.  In particular, if you invoke
+@command{pintos} with the option @option{-j @var{seed}}, timer
+interrupts will come at irregularly spaced intervals.  Within a single
+@var{seed} value, execution will still be reproducible, but timer
+behavior will change as @var{seed} is varied.  Thus, for the highest
+degree of confidence you should test your code with many seed values.
 
 @node Tips
 @section Tips
@@ -327,6 +321,10 @@ join works for.  Don't overdo the output volume, please!
 Be careful to program this function correctly.  You will need its
 functionality for project 2.
 
+Once you've implemented @code{thread_join()}, define
+@code{THREAD_JOIN_IMPLEMENTED} in @file{constants.h}.
+@xref{Conditional Compilation}, for more information.
+
 @node Problem 1-3 Priority Scheduling
 @section Problem 1-3: Priority Scheduling
 
@@ -435,14 +433,6 @@ Test cases should be replacements for the existing @file{test.c}
 file.  Put them in a @file{threads/testcases} directory.
 @xref{TESTCASE}, for more information.
 
-@item
-@b{If a thread finishes, should its children be terminated immediately,
-or should they finish normally?}
-
-You should feel free to decide what semantics you think this
-should have. You need only provide justification for your
-decision.
-
 @item
 @b{Why can't I disable interrupts?}
 
@@ -481,6 +471,18 @@ problems.  There are other, equally correct solutions that do not
 require interrupt manipulation.  However, if you do manipulate
 interrupts and @strong{correctly and fully document it} in your design
 document, we will allow limited use of interrupt disabling.
+
+@item
+@b{What does ``warning: no previous prototype for `@var{function}''
+mean?}
+
+It means that you defined a non-@code{static} function without
+preceding it by a prototype.  Because non-@code{static} functions are
+intended for use by other @file{.c} files, for safety they should be
+prototyped in a header file included before their definition.  To fix
+the problem, add a prototype in a header file that you include, or, if
+the function isn't actually used by other @file{.c} files, make it
+@code{static}.
 @end enumerate
 
 @item Alarm Clock FAQs