@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
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
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
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 may support @file{.} and @file{..} for a small amount of extra
+credit.
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.
+Update the @code{open} system call so that it can also open directories.
+Passing @file{.} as the argument to @code{open} must open the current
+directory, regardless of whether @file{.} and @file{..} are fully
+implemented. Of the existing system calls, only @code{close} needs to
+accept a file descriptor for a directory.
+
Implement the following new system calls:
@deftypefn {System Call} bool chdir (const char *@var{dir})
@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},
+regardless of whether they are implemented.
+
+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
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. 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.
-
@node Buffer Cache
@subsection Buffer Cache
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
@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 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.
+If you don't implement @file{.} and @file{..}, then this is not a
+special case. If you do, then it is equivalent to @samp{/x}. That is,
+the root directory is its own parent.
@end table
@node Buffer Cache FAQ
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.
projects / pintos-anon / blobdiff