-a successful exit. Other values may be used to indicate user-defined
-conditions (usually errors).
-
-@item SYS_exec
-@itemx pid_t exec (const char *@var{file})
-Run the executable in @var{file} and return the new process's program
-id (pid). If there is an error loading this program, returns pid -1,
-which otherwise should not be a valid id number.
-
-@item SYS_join
-@itemx int join (pid_t @var{pid})
-Joins the process @var{pid}, using the join rules from the last
-assignment, and returns the process's exit status. If the process was
-terminated by the kernel (i.e.@: killed due to an exception), the exit
-status should be -1. If the process was not a child of the calling
-process, the return value is undefined (but kernel operation must not
-be disrupted).
-
-@item SYS_create
-@itemx bool create (const char *@var{file}, unsigned @var{initial_size})
-Create a new file called @var{file} initially @var{initial_size} bytes
-in size. Returns -1 if failed, 0 if OK.
-
-@item SYS_remove
-@itemx bool remove (const char *@var{file})
-Delete the file called @var{file}. Returns -1 if failed, 0 if OK.
-
-@item SYS_open
-@itemx int open (const char *@var{file})
-Open the file called @var{file}. Returns a nonnegative integer handle
+success and nonzero values indicate errors.
+@end deftypefn
+
+@deftypefn {System Call} pid_t exec (const char *@var{cmd_line})
+Runs the executable whose name is given in @var{cmd_line}, passing any
+given arguments, and returns the new process's program id (pid). Must
+return pid -1, which otherwise should not be a valid pid, if
+the program cannot load or run for any reason.
+Thus, the parent process cannot return from the @code{exec} until it
+knows whether the child process successfully loaded its executable.
+You must use appropriate synchronization to ensure this.
+@end deftypefn
+
+@deftypefn {System Call} int wait (pid_t @var{pid})
+Waits for a child process @var{pid} and retrieves the child's exit status.
+
+If @var{pid} is still alive, waits until it terminates. Then, returns
+the status that @var{pid} passed to @code{exit}. If @var{pid} did not
+call @code{exit()}, but was terminated by the kernel (e.g.@: killed
+due to an exception), @code{wait(pid)} must return -1. It is perfectly
+legal for a parent process to wait for child processes that have already
+terminated by the time the parent calls @code{wait}, but the kernel must
+still allow the parent to retrieve its child's exit status, or learn
+that the child was terminated by the kernel.
+
+@code{wait} must fail and return -1 immediately if any of the
+following conditions is true:
+@itemize @bullet
+@item
+@var{pid} does not refer to a direct child of the calling process.
+@var{pid} is a direct child of the calling process if and
+only if the calling process received @var{pid} as a return value
+from a successful call to @code{exec}.
+
+Note that children are not inherited: if @var{A} spawns child @var{B}
+and @var{B} spawns child process @var{C}, then @var{A} cannot wait for
+@var{C}, even if @var{B} is dead. A call to @code{wait(C)} by process
+@var{A} must fail. Similarly, orphaned processes are not assigned to
+a new parent if their parent process exits before they do.
+
+@item
+The process that calls @code{wait} has already called @code{wait} on
+@var{pid}. That is, a process may wait for any given child at most
+once.
+@end itemize
+
+Processes may spawn any number of children, wait for them in any order,
+and may even exit without having waited for some or all of their children.
+Your design should consider all the ways in which waits can occur.
+All of a process's resources, including its @struct{thread}, must be
+freed whether its parent ever waits for it or not, and regardless of
+whether the child exits before or after its parent.
+
+You must ensure that Pintos does not terminate until the initial
+process exits. The supplied Pintos code tries to do this by calling
+@func{process_wait} (in @file{userprog/process.c}) from @func{main}
+(in @file{threads/init.c}). We suggest that you implement
+@func{process_wait} according to the comment at the top of the
+function and then implement the @code{wait} system call in terms of
+@func{process_wait}.
+
+Implementing this system call requires considerably more work than any
+of the rest.
+@end deftypefn
+
+@deftypefn {System Call} bool create (const char *@var{file}, unsigned @var{initial_size})
+Creates a new file called @var{file} initially @var{initial_size} bytes
+in size. Returns true if successful, false otherwise.
+Creating a new file does not open it: opening the new file is a
+separate operation which would require a @code{open} system call.
+@end deftypefn
+
+@deftypefn {System Call} bool remove (const char *@var{file})
+Deletes the file called @var{file}. Returns true if successful, false
+otherwise.
+A file may be removed regardless of whether it is open or closed, and
+removing an open file does not close it. @xref{Removing an Open
+File}, for details.
+@end deftypefn
+
+@deftypefn {System Call} int open (const char *@var{file})
+Opens the file called @var{file}. Returns a nonnegative integer handle