Update docs.

[pintos-anon] / doc / filesys.texi

diff --git a/doc/filesys.texi b/doc/filesys.texi
index 36d92e32903480b79bd7adc5a991dc04bc24d780..804c5a7344c2d8e8f695d8d8a1f0f93e68d50aa5 100644 (file)
--- a/doc/filesys.texi
+++ b/doc/filesys.texi
@@ -1,4 +1,4 @@
-@node Project 4--File Systems, , Project 3--Virtual Memory, Top
+@node Project 4--File Systems, Multilevel Feedback Scheduling, Project 3--Virtual Memory, Top
 @chapter Project 4: File Systems
 
 In the previous two assignments, you made extensive use of a
@@ -23,27 +23,7 @@ filesystem implementation.
 
 FIXME FIXME FIXME
 The first step is to understand the default filesystem provided by the
-base code.  The first things you should look at are
-@file{threads/init.c} and @file{filesys/fsutil.c}: there are special
-command line arguments to Pintos which are used to format and
-manipulate the emulated disk.  Specifically, @option{-f} formats the
-file system disk for use with Pintos, and @option{-cp @var{src}
-@var{dst}} copies @var{src} on the Unix filesystem to @var{dst} on the
-file system disk.  With this information, you should be able to
-compile the base code and try out the command: @samp{pintos -f -cp
-./small small} to copy the file @file{small} from your working
-directory into the Pintos file system.
-
-FIXME FIXME FIXME
-One thing you should realize immediately is that, until you use the
-above operation to copy the shell (or whatever your initial program
-is) to the emulated disk, Pintos will be unable to do very much useful
-work (it'll try to open the shell and fail, thereby quitting out).  You
-will also find that you won't be able to do interesting things until
-you copy a variety of programs to the disk.  A useful technique, once
-your inode formats are finalized, is to create a clean reference disk
-and copy that over whenever you trash your disk beyond a useful state
-(which will probably happen quite often while debugging).
+base code.  
 
 @menu
 * File System New Code::        
@@ -55,7 +35,7 @@ and copy that over whenever you trash your disk beyond a useful state
 * File System FAQs::            
 @end menu
 
-@node File System New Code, Problem 4-1 Large Files, Project 4--File Systems, Project 4--File Systems
+@node File System New Code
 @section New Code
 
 Here are some files that are probably new to you.  These are in the
@@ -110,7 +90,7 @@ which you will remove.
 While most of your work will be in @file{filesys}, you should be
 prepared for interactions with all previous parts (as usual).
 
-@node Problem 4-1 Large Files, Problem 4-2 File Growth, File System New Code, Project 4--File Systems
+@node Problem 4-1 Large Files
 @section Problem 4-1: Large Files
 
 Modify the file system to allow the maximum size of a file to be as
@@ -123,7 +103,7 @@ size of a file is limited by the number of pointers that will fit in
 one disk sector.  Increasing the limit to 8 MB will require you to
 implement doubly-indirect blocks.
 
-@node Problem 4-2 File Growth, Problem 4-3 Subdirectories, Problem 4-1 Large Files, Project 4--File Systems
+@node Problem 4-2 File Growth
 @section Problem 4-2: File Growth
 
 Implement extensible files.  In the basic file system, the file size
@@ -136,7 +116,7 @@ the root directory file to expand beyond its current limit of ten
 files.  Make sure that concurrent accesses to the file header remain
 properly synchronized.
 
-@node Problem 4-3 Subdirectories, Problem 4-4 Buffer Cache, Problem 4-2 File Growth, Project 4--File Systems
+@node Problem 4-3 Subdirectories
 @section Problem 4-3: Subdirectories
 
 Implement a hierarchical name space.  In the basic file system, all
@@ -179,7 +159,7 @@ is straightforward once the above syscalls are implemented.  If Unix,
 these are programs rather than built-in shell commands, but
 @command{cd} is a shell command.  (Why?)
 
-@node Problem 4-4 Buffer Cache, File System Design Document Requirements, Problem 4-3 Subdirectories, Project 4--File Systems
+@node Problem 4-4 Buffer Cache
 @section Problem 4-4: Buffer Cache
 
 Modify the file system to keep a cache of file blocks.  When a request
@@ -218,7 +198,7 @@ demonstrate the performance improvement.
 Note that write-behind makes your filesystem more fragile in the face
 of crashes.  Therefore, you should implement some manner to
 periodically write all cached blocks to disk.  If you have
-@code{timer_msleep()} from the first project working, this is an
+@code{timer_sleep()} from the first project working, this is an
 excellent application for it.
 
 Likewise, read-ahead is only really useful when done asynchronously.
@@ -235,7 +215,7 @@ making any read-ahead and write-behind threads halt when Pintos is
 ``done'' (when the user program has completed, etc), so that Pintos
 will halt normally and print its various statistics.
 
-@node File System Design Document Requirements, File System FAQs, Problem 4-4 Buffer Cache, Project 4--File Systems
+@node File System Design Document Requirements
 @section Design Document Requirements
 
 As always, submit a design document file summarizing your design.  Be
@@ -254,7 +234,7 @@ in the cache? How did you choose elements to evict from the cache?
 How and when did you flush the cache?
 @end itemize
 
-@node File System FAQs,  , File System Design Document Requirements, Project 4--File Systems
+@node File System FAQs
 @section FAQ
 
 @enumerate 1