Update docs.

[pintos-anon] / doc / filesys.texi

diff --git a/doc/filesys.texi b/doc/filesys.texi
index 7628eb4856c08d77e1cfae35e65abbd68ccc8c06..b496de763334f2437e48924ea56129becc678d39 100644 (file)
--- a/doc/filesys.texi
+++ b/doc/filesys.texi
@@ -21,29 +21,8 @@ parts work together so that you can run VM and your filesystem at the
 same time.  Plus, keeping VM is a great way to stress-test your
 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).
+Your submission should define @code{THREAD_JOIN_IMPLEMENTED} in
+@file{constants.h} (@pxref{Conditional Compilation}).
 
 @menu
 * File System New Code::        
@@ -229,17 +208,16 @@ request for disk block 2 is handled asynchronously.  In other words,
 the process will block to wait for disk block 1, but should not block
 waiting for disk block 2.
 
-FIXME
 When you're implementing this, please make sure you have a scheme for
 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.
+will halt normally and the disk contents will be consistent.
 
 @node File System Design Document Requirements
 @section Design Document Requirements
 
 As always, submit a design document file summarizing your design.  Be
-sure to cover the following points :
+sure to cover the following points:
 
 @itemize @bullet
 @item
@@ -296,24 +274,21 @@ document.
 @b{What exec modes for running Pintos do I absolutely need to
 support?}
 
-FIXME FIXME
-The most standard mode is to run your Pintos with all the command
-flags on one command line, like this: @samp{pintos -f -cp shell
-shell -ex "shell"}.  However, you also need to support these flags
-individually---especially since that's how the grader tests your
-program.  Thus, you should be able to run the above instead as:
+You also need to support the @option{-f}, @option{-ci}, and
+@option{-ex} flags individually, and you need to handle them when
+they're combined, like this: @samp{pintos -f -ci shell 12345 -ex
+"shell"}.  Thus, you should be able to treat the above as equivalent
+to:
 
-FIXME
 @example
 pintos -f
-pintos -cp shell shell
+pintos -ci shell 12345
 pintos -ex "shell"
 @end example
 
-Note that this also provides a way for you to validate that your disks
-are really persistent.  This is a common problem with a write behind
-cache: if you don't shut down properly it will leave the disk in an
-inconsistent state.
+If you don't change the filesystem interface, then this should already
+be implemented properly in @file{threads/init.c} and
+@file{filesys/fsutil.c}.
 
 @item
 @b{Will you test our file system with a different @code{DISK_SECTOR_SIZE}?}