Sync with sources.

[pintos-anon] / doc / vm.texi

diff --git a/doc/vm.texi b/doc/vm.texi
index 544701a5b90844f24588e3d5d7dadc81d0244ec9..28754c76da50086d0dfa96ad63b71e1ab67e7df9 100644 (file)
--- a/doc/vm.texi
+++ b/doc/vm.texi
@@ -483,8 +483,7 @@ allocate additional pages as necessary.
 
 Allocate additional pages only if they ``appear'' to be stack accesses.
 Devise a heuristic that attempts to distinguish stack accesses from
 
 Allocate additional pages only if they ``appear'' to be stack accesses.
 Devise a heuristic that attempts to distinguish stack accesses from

-other accesses.  You can retrieve the user program's current stack
-pointer from the @struct{intr_frame}'s @code{esp} member.
+other accesses.

 
 User programs are buggy if they write to the stack below the stack
 pointer, because typical real OSes may interrupt a process at any time
 
 User programs are buggy if they write to the stack below the stack
 pointer, because typical real OSes may interrupt a process at any time


@@ -500,9 +499,24 @@ not be restartable in a straightforward fashion.)  Similarly, the
 @code{PUSHA} instruction pushes 32 bytes at once, so it can fault 32
 bytes below the stack pointer.
 
 @code{PUSHA} instruction pushes 32 bytes at once, so it can fault 32
 bytes below the stack pointer.
 

+You will need to be able to obtain the current value of the user
+program's stack pointer.  Within a system call or a page fault generated
+by a user program, you can retrieve it from @code{esp} member of the
+@struct{intr_frame} passed to @func{syscall_handler} or
+@func{page_fault}, respectively.  If you verify user pointers before
+accessing them (@pxref{Accessing User Memory}), these are the only cases
+you need to handle.  On the other hand, if you depend on page faults to
+detect invalid memory access, you will need to handle another case,
+where a page fault occurs in the kernel.  Reading @code{esp} out of the
+@struct{intr_frame} passed to @func{page_fault} in that case will obtain
+the kernel stack pointer, not the user stack pointer.  You will need to
+arrange another way, e.g.@: by saving @code{esp} into @struct{thread} on
+the initial transition from user to kernel mode.
+

 You may impose some absolute limit on stack size, as do most OSes.
 You may impose some absolute limit on stack size, as do most OSes.

-(Some OSes make the limit user-adjustable, e.g.@: with the
-@command{ulimit} command on many Unix systems.)
+Some OSes make the limit user-adjustable, e.g.@: with the
+@command{ulimit} command on many Unix systems.  On many GNU/Linux systems,
+the default limit is 8 MB.

 
 The first stack page need not be allocated lazily.  You can initialize
 it with the command line arguments at load time, with no need to wait
 
 The first stack page need not be allocated lazily.  You can initialize
 it with the command line arguments at load time, with no need to wait


@@ -580,9 +594,15 @@ 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.
 
 @command{diffstat} program.  The final row gives total lines inserted
 and deleted; a changed line counts as both an insertion and a deletion.
 

-This summary is relative to the Pintos base code, but we started from
-the reference solution to project 2.  @xref{Project 2 FAQ}, for the
-summary of project 2.
+This summary is relative to the Pintos base code, but the reference
+solution for project 3 starts from the reference solution to project 2.
+@xref{Project 2 FAQ}, for the summary of project 2.
+
+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
  Makefile.build       |    4 
 
 @verbatim
  Makefile.build       |    4