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.
@deftypefn {System Call} int wait (pid_t @var{pid})
Waits for process @var{pid} to die and returns the status it passed to
@code{exit}. Returns -1 if @var{pid}
-was terminated by the kernel (i.e.@: killed due to an exception). If
+was terminated by the kernel (e.g.@: killed due to an exception). If
@var{pid} is does not refer to a child of the
calling thread, or if @code{wait} has already been successfully
called for the given @var{pid}, returns -1 immediately, without
@var{buffer}. Returns the number of bytes actually read (0 at end of
file), or -1 if the file could not be read (due to a condition other
than end of file). Fd 0 reads from the keyboard using
-@func{kbd_getc}.
+@func{kbd_getc}. (Keyboard input will not work if you pass the
+@option{-v} option to @command{pintos}.)
Consider implementing this function in terms of @func{file_read}.
@end deftypefn
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. Otherwise,
+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.