+@deftypefn {System Call} int write (int @var{fd}, const void *@var{buffer}, unsigned @var{size})
+Writes @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.
+
+Writing past end-of-file would normally extend the file, but file growth
+is not implemented by the basic file system. The expected behavior is
+to write as many bytes as possible up to end-of-file and return the
+actual number written, or -1 if no bytes could be written at all.
+
+Fd 1 writes to the console. Your code to write to the console should
+write all of @var{buffer} in one call to @func{putbuf}, at least as
+long as @var{size} is not bigger than a few hundred bytes. (It is
+reasonable to break up larger buffers.) Otherwise,
+lines of text output by different processes may end up interleaved on
+the console, confusing both human readers and our grading scripts.
+
+Consider implementing this function in terms of @func{file_write}.
+@end deftypefn
+
+@deftypefn {System Call} 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.)
+
+A seek past the current end of a file is not an error. A later read
+obtains 0 bytes, indicating end of file. A later write extends the
+file, filling any unwritten gap with zeros. (However, in Pintos files
+have a fixed length until project 4 is complete, so writes past end of
+file will return an error.) These semantics are implemented in the
+file system and do not require any special effort in system call
+implementation.
+
+Consider implementing this function in terms of @func{file_seek}.
+@end deftypefn
+
+@deftypefn {System Call} 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.
+
+Consider implementing this function in terms of @func{file_tell}.
+@end deftypefn
+
+@deftypefn {System Call} void close (int @var{fd})
+Closes file descriptor @var{fd}.
+Exiting or terminating a process implicitly closes all its open file
+descriptors, as if by calling this function for each one.
+
+Consider implementing this function in terms of @func{file_close}.
+@end deftypefn
+
+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 need to provide ways to read and write data
+in user virtual address space.
+You need this ability 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.
+This can be a bit tricky: what if the user provides an invalid
+pointer, a pointer into kernel memory, or a block
+partially in one of those regions? You should handle these cases by
+terminating the user process. We recommend
+writing and testing this code before implementing any other system
+call functionality.
+
+You must synchronize system calls so that
+any number of user processes can make them at once. In particular, it
+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 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
+recommend against modifying code in the @file{filesys} directory.}
+
+We have provided you a user-level 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 uses a little inline
+assembly code to invoke the system call and (if appropriate) returns the
+system call's return value.
+
+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, panic, fail an assertion, or otherwise malfunction. It is
+important to emphasize this point: our tests will try to break your
+system calls in many, many ways. You need to think of all the corner
+cases and handle them. The sole way a user program should be able to
+cause the OS to halt is by invoking the @code{halt} system call.
+
+If a system call is passed an invalid argument, acceptable options
+include returning an error value (for those calls that return a
+value), returning an undefined value, or terminating the process.
+
+@xref{System Call Details}, for details on how system calls work.
+
+@node Denying Writes to Executables
+@subsection Denying Writes to Executables
+
+Add code to deny writes to files in use as executables. Many OSes do
+this because of the unpredictable results if a process tried to run code
+that was in the midst of being changed on disk. This is especially
+important once virtual memory is implemented in project 3, but it can't
+hurt even now.
+
+You can use @func{file_deny_write} to prevent writes to an open file.
+Calling @func{file_allow_write} on the file will re-enable them (unless
+the file is denied writes by another opener). Closing a file will also
+re-enable writes. Thus, to deny writes to process's executable, you
+must keep it open as long as the process is still running.
+
+@node Project 2 FAQ
+@section FAQ
+
+@table @asis
+@item How much code will I need to write?
+
+Here's a summary of our reference solution, produced by the
+@command{diffstat} program. The final row gives total lines inserted
+and deleted; a changed line counts as both an insertion and a deletion.
+
+The reference solution represents just one possible solution. Many
+other solutions are also possible and many of those differ greatly from
+the reference solution. Some excellent solutions may not modify all the
+files modified by the reference solution, and some may modify files not
+modified by the reference solution.
+
+@verbatim
+ threads/thread.c | 13
+ threads/thread.h | 26 +
+ userprog/exception.c | 8
+ userprog/process.c | 247 ++++++++++++++--
+ userprog/syscall.c | 468 ++++++++++++++++++++++++++++++-
+ userprog/syscall.h | 1
+ 6 files changed, 725 insertions(+), 38 deletions(-)
+@end verbatim
+
+@item The kernel always panics when I run @code{pintos -p @var{file} -- -q}.
+
+Did you format the disk (with @samp{pintos -f})?
+
+Is your file name too long? The file system limits file names to 14
+characters. A command like @samp{pintos -p ../../examples/echo -- -q}
+will exceed the limit. Use @samp{pintos -p ../../examples/echo -a echo
+-- -q} to put the file under the name @file{echo} instead.
+
+Is the file system full?
+
+Does the file system already contain 16 files? The base Pintos file
+system has a 16-file limit.
+
+The file system may be so fragmented that there's not enough contiguous
+space for your file.
+
+@item When I run @code{pintos -p ../file --}, @file{file} isn't copied.
+
+Files are written under the name you refer to them, by default, so in
+this case the file copied in would be named @file{../file}. You
+probably want to run @code{pintos -p ../file -a file --} instead.
+
+@item All my user programs die with page faults.
+
+This will happen if you haven't implemented argument passing
+(or haven't done so correctly). The basic C library for user programs tries
+to read @var{argc} and @var{argv} off the stack. If the stack
+isn't properly set up, this causes a page fault.
+
+@item All my user programs die with @code{system call!}
+
+You'll have to implement system calls before you see anything else.
+Every reasonable program tries to make at least one system call
+(@func{exit}) and most programs make more than that. Notably,
+@func{printf} invokes the @code{write} system call. The default system
+call handler just prints @samp{system call!} and terminates the program.
+Until then, you can use @func{hex_dump} to convince yourself that
+argument passing is implemented correctly (@pxref{Program Startup Details}).
+
+@item How can I can disassemble user programs?
+
+The @command{objdump} (80@var{x}86) or @command{i386-elf-objdump}
+(SPARC) utility can disassemble entire user
+programs or object files. Invoke it as @code{objdump -d
+@var{file}}. You can use GDB's
+@code{disassemble} command to disassemble individual functions
+(@pxref{GDB}).
+
+@item Why do many C include files not work in Pintos programs?
+
+The C library we provide is very limited. It does not include many of
+the features that are expected of a real operating system's C library.
+The C library must be built specifically for the operating system (and
+architecture), since it must make system calls for I/O and memory
+allocation. (Not all functions do, of course, but usually the library
+is compiled as a unit.)
+
+@item Can I use lib@var{foo} in my Pintos programs?
+
+The chances are good that lib@var{foo} uses parts of the C library
+that Pintos doesn't implement. It will probably take at least some
+porting effort to make it work under Pintos. Notably, the Pintos
+user program C library does not have a @func{malloc} implementation.
+
+@item How do I compile new user programs?
+
+Modify @file{src/examples/Makefile}, then run @command{make}.
+
+@item Can I run user programs under a debugger?
+
+Yes, with some limitations. @xref{Debugging User Programs}.
+
+@item What's the difference between @code{tid_t} and @code{pid_t}?
+
+A @code{tid_t} identifies a kernel thread, which may have a user
+process running in it (if created with @func{process_execute}) or not
+(if created with @func{thread_create}). It is a data type used only
+in the kernel.
+
+A @code{pid_t} identifies a user process. It is used by user
+processes and the kernel in the @code{exec} and @code{wait} system
+calls.
+
+You can choose whatever suitable types you like for @code{tid_t} and
+@code{pid_t}. By default, they're both @code{int}. You can make them
+a one-to-one mapping, so that the same values in both identify the
+same process, or you can use a more complex mapping. It's up to you.
+
+@item Keyboard input doesn't work with @command{pintos} option @option{-v}.
+
+Serial input isn't implemented. Don't use @option{-v} if you
+want to use the shell or otherwise need keyboard input.
+@end table
+
+@menu
+* Argument Passing FAQ::
+* System Calls FAQ::
+@end menu
+
+@node Argument Passing FAQ
+@subsection Argument Passing FAQ
+
+@table @asis
+@item Isn't the top of stack off the top of user virtual memory?
+
+The top of stack is at @code{PHYS_BASE}, typically @t{0xc0000000}, which
+is also where kernel virtual memory starts.
+But when the processor pushes data on the stack, it decrements the stack