File system project updates:
[pintos-anon] / doc / filesys.texi
index 7f4bd5c268e1a824abe77e229571c860586dcb51..49117a502ae1fad37b20f1ba9ff1a77b3cb79c44 100644 (file)
@@ -14,10 +14,14 @@ 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.
 
+The tests for project 4 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::      
-* Project 4 FAQ::             
+* Project 4 FAQ::               
 @end menu
 
 @node Project 4 Background
@@ -108,9 +112,10 @@ vulnerable to external fragmentation, that is, it is possible that an
 free.  Eliminate this problem by
 modifying the on-disk inode structure.  In practice, this probably means using
 an index structure with direct, indirect, and doubly indirect blocks.
-(You are welcome to choose a different scheme as long as you explain the
+You are welcome to choose a different scheme as long as you explain the
 rationale for it in your design documentation, and as long as it does
-not suffer from external fragmentation.)
+not suffer from external fragmentation (as does the extent-based file
+system we provide).
 
 You can assume that the disk will not be larger than 8 MB.  You must
 support files as large as the disk (minus metadata).  Each inode is
@@ -131,7 +136,7 @@ that a file cannot exceed the size of the disk (minus metadata).  This
 also applies to the root directory file, which should now be allowed
 to expand beyond its initial limit of 16 files.
 
-The user is allowed to seek beyond the current end-of-file (EOF).  The
+User programs are allowed to seek beyond the current end-of-file (EOF).  The
 seek itself does not extend the file.  Writing at a position past EOF
 extends the file to the position being written, and any gap between the
 previous EOF and the start of the write must be filled with zeros.  A
@@ -159,19 +164,29 @@ retain this limit for individual file name components, or may extend
 it, at your option.  You must allow full path names to be
 much longer than 14 characters.
 
-The current directory is maintained separately for each process.  At
-startup, the initial process's current directory is the root directory.
+Maintain a separate current directory for each process.  At
+startup, set the root as the initial process's current directory.
 When one process starts another with the @code{exec} system call, the
 child process inherits its parent's current directory.  After that, the
 two processes' current directories are independent, so that either
 changing its own current directory has no effect on the other.
+(This is why, under Unix, the @command{cd} command is a shell built-in,
+not an external program.)
 
 Update the existing system calls so that, anywhere a file name is
 provided by the caller, an absolute or relative path name may used.
+The directory separator character is forward slash (@samp{/}).
+You must also support special file names @file{.} and @file{..}, which
+have the same meanings as they do in Unix.
 
 Update the @code{remove} system call so that it can delete empty
-directories in addition to regular files.  Directories can only be
-deleted if they do not contain any files or subdirectories.
+directories in addition to regular files.  Directories may only be
+deleted if they do not contain any files or subdirectories (other than
+@file{.} and @file{..}).
+
+Update the @code{open} system call so that it can also open directories.
+Of the existing system calls, only @code{close} needs to accept a file
+descriptor for a directory.
 
 Implement the following new system calls:
 
@@ -190,23 +205,47 @@ Fails if @var{dir} already exists or if any directory name in
 @file{/a/b/c} does not.
 @end deftypefn
 
-@deftypefn {System Call} void lsdir (void)
-Prints a list of files in the current directory to @code{stdout}, one
-per line, in no particular order.
+@deftypefn {System Call} bool readdir (int @var{fd}, char *@var{name})
+Reads a directory entry from file descriptor @var{fd}, which must
+represent a directory.  If successful, stores the null-terminated file
+name in @var{name}, which must have room for @code{READDIR_MAX_LEN + 1}
+bytes, and returns true.  If no entries are left in the directory,
+returns false.
+
+@file{.} and @file{..} should not be returned by @code{readdir}.
+
+If the directory changes while it is open, then it is acceptable for
+some entries not to be read at all or to be read multiple times.
+Otherwise, each directory entry should be read once, in any order.
+
+@code{READDIR_MAX_LEN} is defined in @file{lib/user/syscall.h}.  If your
+file system supports longer file names than the basic file system, you
+should increase this value from the default of 14.
+@end deftypefn
+
+@deftypefn {System Call} bool isdir (int @var{fd})
+Returns true if @var{fd} represents a directory,
+false if it represents an ordinary file.
+@end deftypefn
+
+@deftypefn {System Call} int inumber (int @var{fd})
+Returns the @dfn{inode number} of the inode associated with @var{fd}.
+Applicable to file descriptors for both files and directories.
+
+An inode number persistently identifies a file or directory.  It is
+unique during the file's existence.  In Pintos, the sector number of the
+inode is suitable for use as an inode number.
 @end deftypefn
 
 We have provided @command{ls} and @command{mkdir} user programs, which
-are 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.
+are straightforward once the above syscalls are implemented.  
+We have also provided @command{pwd}, which is not so straightforward.
+The @command{shell} program implements @command{cd} internally.
 
 The @code{pintos} @option{put} and @option{get} commands should now
 accept full path names, assuming that the directories used in the
-paths have already been created.  This should not require any extra
-effort on your part.
-
-You may support @file{.} and @file{..} for a small amount of extra
-credit.
+paths have already been created.  This should not require any significant
+extra effort on your part.
 
 @node Buffer Cache
 @subsection Buffer Cache
@@ -354,21 +393,10 @@ modified by the reference solution.
  30 files changed, 2721 insertions(+), 286 deletions(-)
 @end verbatim
 
-@item What extra credit opportunities are available?
-
-You may implement Unix-style support for @file{.} and @file{..} in
-relative paths in their projects.
-
-You may submit with VM enabled.
-
 @item Can @code{DISK_SECTOR_SIZE} change?
 
 No, @code{DISK_SECTOR_SIZE} is fixed at 512.  This is a fixed property
 of IDE disk hardware.
-
-@item What's the directory separator character?
-
-Forward slash (@samp{/}).
 @end table
 
 @menu
@@ -392,12 +420,20 @@ You'll need to consider this when deciding your inode organization.
 @subsection Subdirectories FAQ
 
 @table @b
-@item Why is @command{cd} a shell command?
+@item How should a file name like @samp{a//b} be interpreted?
+
+Multiple consecutive slashes are equivalent to a single slash, so this
+file name is the same as @samp{a/b}.
+
+@item How about a file name like @samp{/../x}?
+
+The root directory is its own parent, so it is equivalent to @samp{/x}.
+
+@item How should a file name that ends in @samp{/} be treated?
 
-The current directory of each process is independent.  A @command{cd}
-program could change its own current directory, but that would have no
-effect on the shell.  In fact, Unix-like systems don't provide any way
-for one process to change another's current working directory.
+Most Unix systems allow a slash at the end of the name for a directory,
+and reject other names that end in slashes.  We will allow this
+behavior, as well as simply rejecting a name that ends in a slash.
 @end table
 
 @node Buffer Cache FAQ
@@ -420,8 +456,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.
 
-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.