-access memory at a user virtual address that doesn't have a page
-mapped into it will cause a page fault.
-
-@node Global Requirements
-@section Global Requirements
-
-For testing and grading purposes, we have some simple requirements for
-your output. The kernel should print out the program's name and exit
-status whenever a process exits, e.g.@: @code{shell: exit(-1)}. Aside
-from this, it should print out no other messages. You may understand
-all those debug messages, but we won't, and it just clutters our
-ability to see the stuff we care about.
-
-Additionally, while it may be useful to hard-code which process will
-run at startup while debugging, before you submit your code you must
-make sure that it takes the start-up process name and arguments from
-the @samp{-ex} argument. For example, running @code{pintos run -ex
-"testprogram 1 2 3 4"} will spawn @samp{testprogram 1 2 3 4} as the
-first process.
-
-@node Problem 2-1 Argument Passing
-@section Problem 2-1: Argument Passing
-
-Currently, @func{process_execute} does not support passing arguments
-to new processes. UNIX and other operating systems do allow passing
-command line arguments to a program, which accesses them via the argc,
-argv arguments to main. You must implement this functionality by
-extending @func{process_execute} so that instead of simply taking a
-program file name, it can take a program name with arguments as a
-single string. That is, @code{process_execute("grep foo *.c")} should
-be a legal call. @xref{80x86 Calling Convention}, for information on
-exactly how this works.
-
-@strong{This functionality is extremely important.} Almost all our
-test cases rely on being able to pass arguments, so if you don't get
-this right, a lot of things will not appear to work correctly with our
-tests. If the tests fail, so do you. Fortunately, this part
-shouldn't be too hard.
-
-@node Problem 2-2 System Calls
-@section Problem 2-2: System Calls
-
-Implement the system call handler in @file{userprog/syscall.c} to
-properly deal with all the system calls described below. Currently,
-it ``handles'' system calls by terminating the process. You will need
-to decipher system call arguments and take the appropriate action for
-each.
-
-You are required to support the following system calls, whose syscall
-numbers are defined in @file{lib/syscall-nr.h} and whose C functions
-called by user programs are prototyped in @file{lib/user/syscall.h}:
-
-@table @code
-@item SYS_halt
-@itemx void halt (void)
-Stops Pintos and prints out performance statistics. Note that this
-should be seldom used, since then you lose some information about
-possible deadlock situations, etc.
-
-@item SYS_exit
-@itemx void exit (int @var{status})
-Terminates the current user program, returning @var{status} to the
-kernel. A @var{status} of 0 indicates a successful exit. Other
-values may be used to indicate user-defined error conditions.
-
-@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})
-Create a new file called @var{file}. 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
-called a ``file descriptor'' (fd), or -1 if the file could not be
-opened. File descriptors numbered 0 and 1 are reserved for the
-console. All open files associated with a process should be closed
-when the process exits or is terminated.
-
-@item SYS_filesize
-@itemx int filesize (int @var{fd})
-Returns the size, in bytes, of the file open as @var{fd}, or -1 if the
-file is invalid.
-
-@item SYS_read
-@itemx int read (int @var{fd}, void *@var{buffer}, unsigned @var{size})
-Read @var{size} bytes from the file open as @var{fd} into
-@var{buffer}. Returns the number of bytes actually read, or -1 if the
-file could not be read.
-
-@item SYS_write
-@itemx int write (int @var{fd}, const void *@var{buffer}, unsigned @var{size})
-Write @var{size} bytes from @var{buffer} to the open file @var{fd}.
-Returns the number of bytes actually written, or -1 if the file could
-not be written.
-
-@item SYS_seek
-@itemx void seek (int @var{fd}, unsigned @var{position})
-Changes the next byte to be read or written in open file @var{fd} to
-@var{position}, expressed in bytes from the beginning of the file.
-(Thus, a @var{position} of 0 is the file's start.)
-
-@item SYS_tell
-@itemx unsigned tell (int @var{fd})
-Returns the position of the next byte to be read or written in open
-file @var{fd}, expressed in bytes from the beginning of the file.
-
-@item SYS_close
-@itemx void close (int @var{fd})
-Close file descriptor @var{fd}.
-@end table
-
-The file defines other syscalls. Ignore them for now. You will
-implement some of them in project 3 and the rest in project 4, so be
-sure to design your system with extensibility in mind.
-
-To implement syscalls, you will need to provide a way of copying data
-from the user's virtual address space into the kernel and vice versa.
-This can be a bit tricky: what if the user provides an invalid
-pointer, a pointer into kernel memory, or points to a block that is
-partially in one of those regions? You should handle these cases by
-terminating the user process. You will need this code before you can
-even obtain the system call number, because the system call number is
-on the user's stack in the user's virtual address space. We recommend
-writing and testing this code before implementing any other system
-call functionality.
-
-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
-@file{filesys} directory from multiple threads at once. For now, we
-recommend adding a single lock that controls access to the filesystem
-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
-recommend against modifying code in the @file{filesys} directory.}
-
-We have provided you a function for each system call in
-@file{lib/user/syscall.c}. These provide a way for user processes to
-invoke each system call from a C program. Each of them calls an
-assembly language routine in @file{lib/user/syscall-stub.S}, which in
-turn invokes the system call interrupt and returns.
-
-When you're done with this part, and forevermore, Pintos should be
-bulletproof. Nothing that a user program can do should ever cause the
-OS to crash, halt, assert fail, or otherwise stop running. The sole
-exception is a call to the @code{halt} system call.