X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?p=pintos-anon;a=blobdiff_plain;f=doc%2Fuserprog.texi;h=11d9875ce7beabe78e2ebb8e9079d7402bb31113;hp=8ed52b1e6aca46b28c40c9d4a962ee95ee28f7d5;hb=2ca95dc97c9dd591d0f71f1f4c411b3aeb82d690;hpb=1c2fa3bdca935a36f1fa0a5744ae324d345f884d diff --git a/doc/userprog.texi b/doc/userprog.texi index 8ed52b1..11d9875 100644 --- a/doc/userprog.texi +++ b/doc/userprog.texi @@ -20,9 +20,7 @@ assignment. The ``alarm clock'' functionality may be useful in projects 3 and 4, but it is not strictly required. You might find it useful to go back and reread how to run the tests -(@pxref{Testing}). In particular, the tests for project 2 (and later -projects) will probably run faster if you use the qemu emulator, e.g.@: -via @code{make check PINTOSOPTS='--qemu'}. +(@pxref{Testing}). @menu * Project 2 Background:: @@ -316,11 +314,6 @@ the running process. However, even in the kernel, an attempt to access memory at an unmapped user virtual address will cause a page fault. -You must handle memory fragmentation gracefully, that is, a process that -needs @var{N} pages of user virtual memory must not require those pages -to be contiguous in physical memory (or, equivalently, in kernel virtual -memory). - @menu * Typical Memory Layout:: @end menu @@ -573,13 +566,13 @@ 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 foo 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.) +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, look at @func{strtok_r}, prototyped in @file{lib/string.h} and @@ -692,8 +685,7 @@ Reads @var{size} bytes from the file open as @var{fd} into @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}. (Keyboard input will not work if you pass the -@option{-v} option to @command{pintos}.) +@func{input_getc}. @end deftypefn @deftypefn {System Call} int write (int @var{fd}, const void *@var{buffer}, unsigned @var{size}) @@ -912,12 +904,6 @@ 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. - -You are probably passing @option{-v} to @command{pintos}, but -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