+System call infrastructure (@pxref{System Calls}). Implement enough
+code to read the system call number from the user stack and dispatch to
+a handler based on it.
+
+@item
+The @code{exit} system call. Every user program that finishes in the
+normal way calls @code{exit}. Even a program that returns from
+@func{main} calls @code{exit} indirectly (see @func{_start} in
+@file{lib/user/entry.c}).
+
+@item
+The @code{write} system call for writing to fd 1, the system console.
+All of our test programs write to the console (the user process version
+of @func{printf} is implemented this way), so they will all malfunction
+until @code{write} is available.
+
+@item
+For now, change @func{process_wait} to an infinite loop (one that waits
+forever). The provided implementation returns immediately, so Pintos
+will power off before any processes actually get to run. You will
+eventually need to provide a correct implementation.
+@end itemize
+
+After the above are implemented, user processes should work minimally.
+At the very least, they can write to the console and exit correctly.
+You can then refine your implementation so that some of the tests start
+to pass.
+
+@node Project 2 Requirements
+@section Requirements
+
+@menu
+* Project 2 Design Document::
+* Process Termination Messages::
+* Argument Passing::
+* System Calls::
+* Denying Writes to Executables::
+@end menu
+
+@node Project 2 Design Document
+@subsection Design Document
+
+Before you turn in your project, you must copy @uref{userprog.tmpl, ,
+the project 2 design document template} into your source tree under the
+name @file{pintos/src/userprog/DESIGNDOC} and fill it in. We recommend
+that you read the design document template before you start working on
+the project. @xref{Project Documentation}, for a sample design document
+that goes along with a fictitious project.
+
+@node Process Termination Messages
+@subsection Process Termination Messages
+
+Whenever a user process terminates, because it called @code{exit}
+or for any other reason, print the process's name
+and exit code, formatted as if printed by @code{printf ("%s:
+exit(%d)\n", @dots{});}. The name printed should be the full name
+passed to @func{process_execute}, omitting command-line arguments.
+Do not print these messages when a kernel thread that is not a user
+process terminates, or
+when the @code{halt} system call is invoked. The message is optional
+when a process fails to load.
+
+Aside from this, don't print any other
+messages that Pintos as provided doesn't already print. You may find
+extra messages useful during debugging, but they will confuse the
+grading scripts and thus lower your score.
+
+@node Argument Passing
+@subsection Argument Passing
+
+Currently, @func{process_execute} does not support passing arguments to
+new processes. Implement this functionality, by extending
+@func{process_execute} so that instead of simply taking a program file
+name as its argument, it divides it into words at spaces. The first
+word is the program name, the second word is the first argument, and so
+on. That is, @code{process_execute("grep foo bar")} should run
+@command{grep} passing two arguments @code{foo} and @code{bar}.
+
+Within a command line, multiple spaces are equivalent to a single
+space, so that @code{process_execute("grep @w{ }foo @w{ }@w{ }bar")}
+is equivalent to our original example. You can impose a reasonable
+limit on the length of the command line arguments. For example, you
+could limit the arguments to those that will fit in a single page (4
+kB). (There is an unrelated limit of 128 bytes on command-line
+arguments that the @command{pintos} utility can pass to the kernel.)
+
+You can parse argument strings any way you like. If you're lost,