The grading scripts check the file system's correctness based on the
contents of the file copied out in the second run. This means that your
project will not pass any of the extended file system tests until the
-file system is implemented well enough to support @program{tar}, the
+file system is implemented well enough to support @command{tar}, the
Pintos user program that produces the file that is copied out. The
-@program{tar} program is fairly demanding (it requires both extensible
+@command{tar} program is fairly demanding (it requires both extensible
file and subdirectory support), so this will take some work. Until
then, you can ignore errors from @command{make check} regarding the
extracted file system.
@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.
+Returns the @dfn{inode number} of the inode associated with @var{fd},
+which may represent an ordinary file or a directory.
An inode number persistently identifies a file or directory. It is
unique during the file's existence. In Pintos, the sector number of the
@func{filesys_done}, so that halting Pintos flushes the cache.
If you have @func{timer_sleep} from the first project working, write-behind is
-an excellent application. If you're still using the base
-implementation of @func{timer_sleep}, be aware that it busy-waits, which
-is not acceptable here (or elsewhere). If @func{timer_sleep}'s delays seem too
-short or too long, reread the explanation of the @option{-r} option to
-@command{pintos} (@pxref{Debugging versus Testing}).
+an excellent application. Otherwise, you may implement a less general
+facility, but make sure that it does not exhibit busy-waiting.
You should also implement @dfn{read-ahead}, that is,
automatically fetch the next block of a file
projects / pintos-anon / blobdiff