Clarify.

[pintos-anon] / doc / filesys.texi

diff --git a/doc/filesys.texi b/doc/filesys.texi
index 345183c29ec37514cf4cd41e328304b0b17b6f09..df1b25c4d1d4a115d338e16371bb958e0b81add4 100644 (file)
--- a/doc/filesys.texi
+++ b/doc/filesys.texi
@@ -128,8 +128,9 @@ only once).
 Make sure that directories can expand beyond their original size just
 as any other file can.
 
-To take advantage of hierarchical name spaces in user programs,
-provide the following syscalls:
+Update the existing system calls so that, anywhere a file name is
+provided by the caller, an absolute or relative path name may used.
+Also, implement the following new system calls:
 
 @table @code
 @item SYS_chdir
@@ -150,7 +151,7 @@ per line.
 @end table
 
 Also write the @command{ls} and @command{mkdir} user programs.  This
-is straightforward once the above syscalls are implemented.  If Unix,
+is straightforward once the above syscalls are implemented.  In Unix,
 these are programs rather than built-in shell commands, but
 @command{cd} is a shell command.  (Why?)
 
@@ -167,7 +168,19 @@ replacement algorithm.  Experiment to see what combination of accessed,
 dirty, and other information results in the best performance, as
 measured by the number of disk accesses.  (For example, metadata is
 generally more valuable to cache than data.)  Document your
-replacement algoritm in your design document.
+replacement algorithm in your design document.
+
+The provided file system code uses a ``bounce buffer'' in @struct{file}
+to translate the disk's sector-by-sector interface into the system call
+interface's byte-by-byte interface.  It needs per-file buffers because,
+without them, there's no other good place to put sector
+data.@footnote{The stack is not a good place because large objects
+should not be allocated on the stack.  A 512-byte sector is pushing the
+limit there.}  As part of implementing the buffer cache, you should get
+rid of these bounce buffers.  Instead, copy data into and out of sectors
+in the buffer cache directly.  You will probably need some
+synchronization to prevent sectors from being evicted from the cache
+while you are using them.
 
 In addition to the basic file caching scheme, your implementation
 should also include the following enhancements:
@@ -191,7 +204,7 @@ to perform better than on the original file system implementation, and
 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
+of crashes.  Therefore, you should
 periodically write all cached blocks to disk.  If you have
 @func{timer_sleep} from the first project working, this is an
 excellent application for it.
@@ -270,11 +283,10 @@ document.
 @b{What exec modes for running Pintos do I absolutely need to
 support?}
 
-You also need to support the @option{-f}, @option{-ci}, and
-@option{-ex} flags individually, and you need to handle them when
+You also need to support the @option{-f}, @option{-ci}, @option{-co},
+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:
+"shell"}.  Thus, you should be able to treat the above as equivalent to:
 
 @example
 pintos -f
@@ -286,6 +298,9 @@ 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}.
 
+You must also implement the @option{-q} option and make sure that data
+gets flushed out to disk properly when it is used.
+
 @item
 @b{Will you test our file system with a different @code{DISK_SECTOR_SIZE}?}
 
@@ -298,6 +313,11 @@ of IDE disk hardware.
 Yes.  Anything stored in @struct{inode} takes up space on disk,
 so you must include this in your calculation of how many entires will
 fit in a single disk sector.
+
+@item
+@b{What's the directory separator character?}
+
+Forward slash (@samp{/}).
 @end enumerate
 
 @menu