Things you @emph{don't} need: an explanation of the pre-existing
Pintos code, an explanation of the project spec, justification for the
-project (e.g.@: we don't need you to explain to us why filesystems are
+project (e.g.@: we don't need you to explain to us why file systems are
important to an operating system), a play-by-play of every change you
made to the system, any other pontificating. (You may laugh at some
of the things listed above, but we've gotten all of them in the past.)
@chapter Project 4: File Systems
In the previous two assignments, you made extensive use of a
-filesystem without actually worrying about how it was implemented
+file system without actually worrying about how it was implemented
underneath. For this last assignment, you will fill in the
-implementation of the filesystem. You will be working primarily in
+implementation of the file system. You will be working primarily in
the @file{filesys} directory.
You should build on the code you wrote for the previous assignments.
However, if you wish, you may turn off your VM features, as they are
-not vital to making the filesystem work. (You will need to edit
+not vital to making the file system work. (You will need to edit
@file{filesys/Makefile.vars} to fully disable VM.) All of the
functionality needed for project 2 (argument passing, syscalls and
multiprogramming) must work in your filesys submission.
On the other hand, one of the particular charms of working on
operating systems is being able to use what you build, and building
full-featured systems. Therefore, you should strive to make all the
-parts work together so that you can run VM and your filesystem at the
+parts work together so that you can run VM and your file system at the
same time. Plus, keeping VM is a great way to stress-test your
-filesystem implementation.
+file system implementation.
Your submission should define @code{THREAD_JOIN_IMPLEMENTED} in
@file{constants.h} (@pxref{Conditional Compilation}).
@table @file
@item fsutil.c
-Simple utilities for the filesystem that are accessible from the
+Simple utilities for the file system that are accessible from the
kernel command line.
@item filesys.h
file system translates these calls into physical disk operations.
All the basic functionality is there in the code above, so that the
-filesystem is usable right off the bat. In fact, you've been using it
+file system is usable right off the bat. In fact, you've been using it
in the previous two projects. However, it has severe limitations
which you will remove.
to perform better than on the original file system implementation, and
demonstrate the performance improvement.
-Note that write-behind makes your filesystem more fragile in the face
+Note that write-behind makes your file system more fragile in the face
of crashes. Therefore, you should
periodically write all cached blocks to disk. If you have
@func{timer_sleep} from the first project working, this is an
pintos -ex "shell"
@end example
-If you don't change the filesystem interface, then this should already
+If you don't change the file system interface, then this should already
be implemented properly in @file{threads/init.c} and
@file{filesys/fsutil.c}.
@func{serial_init_queue} to switch to that mode. Finally,
@func{timer_calibrate} calibrates the timer for accurate short delays.
-If the filesystem is compiled in, as it will be in project 2 and
+If the file system is compiled in, as it will be in project 2 and
later, we now initialize the disks with @func{disk_init}, then the
-filesystem with @func{filesys_init}, and run any operations that were
+file system with @func{filesys_init}, and run any operations that were
requested on the kernel command line with @func{fsutil_run}.
Boot is complete, so we print a message.
@anchor{Synchronizing File Access}
You must make sure that system calls are properly synchronized so that
any number of user processes can make them at once. In particular, it
-is not safe to call into the filesystem code provided in the
+is not safe to call into the file system code provided in the
@file{filesys} directory from multiple threads at once. For now, we
-recommend adding a single lock that controls access to the filesystem
+recommend adding a single lock that controls access to the file system
code. You should acquire this lock before calling any functions in
the @file{filesys} directory, and release it afterward. Don't forget
that @func{process_execute} also accesses files. @strong{For now, we
projects / pintos-anon / commitdiff