Update docs to say that a pointer to an inode should not limit you to

[pintos-anon] / doc / filesys.texi

diff --git a/doc/filesys.texi b/doc/filesys.texi
index 7f4bd5c268e1a824abe77e229571c860586dcb51..f2c7da9159880a3e0d0d11fac9dd6989c26b126b 100644 (file)
--- a/doc/filesys.texi
+++ b/doc/filesys.texi
@@ -14,6 +14,10 @@ filesys submission.  If you build on project 3, then all of the project
 @file{filesys/Make.vars} to enable VM functionality.  You can receive up
 to 5% extra credit if you do enable VM.
 
 @file{filesys/Make.vars} to enable VM functionality.  You can receive up
 to 5% extra credit if you do enable VM.
 

+The tests for project 4 (and later projects) will probably run faster if
+you use the qemu emulator, e.g.@: via @code{make check
+PINTOSOPTS='--qemu'}.
+

 @menu
 * Project 4 Background::        
 * Project 4 Requirements::      
 @menu
 * Project 4 Background::        
 * Project 4 Requirements::      


@@ -420,8 +424,10 @@ corresponding sector from disk when it's created.  Keeping extra
 copies of inodes would subvert the 64-block limitation that we place
 on your cache.
 
 copies of inodes would subvert the 64-block limitation that we place
 on your cache.
 

-You can store a pointer to inode data in @struct{inode}, if you want,
-and you can store other information to help you find the inode when you
+You can store a pointer to inode data in @struct{inode}, but it you do
+so you should carefully make sure that this does not limit your OS to 64
+simultaneously open files.
+You can also store other information to help you find the inode when you

 need it.  Similarly, you may store some metadata along each of your 64
 cache entries.
 
 need it.  Similarly, you may store some metadata along each of your 64
 cache entries.