Clarify.

[pintos-anon] / doc / filesys.texi

diff --git a/doc/filesys.texi b/doc/filesys.texi
index 8b7bdb46f1d753032bd2892bcd19e35b2b2f0d3f..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
@@ -169,6 +170,18 @@ measured by the number of disk accesses.  (For example, metadata is
 generally more valuable to cache than data.)  Document your
 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: