X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=doc%2Fuserprog.texi;h=25b7a70b7c6679bae217742b8e5203060b29abf3;hb=064e19becdc8969ddb605223b340606706a33f86;hp=525e8ced27e8699604c223a7996c4cd5bf9e5710;hpb=031abf164a9867f8f65d724eeeb298dc5f4ae8a6;p=pintos-anon diff --git a/doc/userprog.texi b/doc/userprog.texi index 525e8ce..25b7a70 100644 --- a/doc/userprog.texi +++ b/doc/userprog.texi @@ -254,6 +254,19 @@ another reason. The name printed should be the full name passed to @func{process_execute}, except that it is acceptable to truncate it to 15 characters to allow for the limited space in @struct{thread}. +@itemize @minus +@item +Do not print a message when a kernel thread that is not a process +terminates. + +@item +Do not print messages about process termination for the @code{halt} +system call. + +@item +No message need be printed when a process that fails to load. +@end itemize + @item Aside from this, the kernel should print out no other messages that Pintos as provided doesn't already print. You @@ -345,7 +358,7 @@ conditions (usually errors). @itemx pid_t exec (const char *@var{cmd_line}) Runs the executable whose name is given in @var{cmd_line}, passing any given arguments, and returns the new process's program id (pid). If -there is an error loading this program, returns pid -1, which +there is an error loading this program, may return pid -1, which otherwise should not be a valid id number. @item SYS_join @@ -507,7 +520,8 @@ isn't properly set up yet, this causes a page fault. @samp{system call!}.} Every reasonable program tries to make at least one system call -(@func{exit}) and most programs make more than that. The default +(@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. You'll have to implement 2-2 before you see anything more interesting. Until then, you can use @func{hex_dump} to convince @@ -818,7 +832,7 @@ After we push all of the strings onto the stack, we adjust the stack pointer so that it is word-aligned: that is, we move it down to the next 4-byte boundary. This is required because we will next be placing several words of data on the stack, and they must be aligned -in order to be read correctly. In our example, as you'll see below, +to be read correctly. In our example, as you'll see below, the strings start at address @t{0xffed}. One word below that would be at @t{0xffe9}, so we could in theory put the next word on the stack there. However, since the stack pointer should always be