X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=doc%2Fvm.texi;h=c2943cacecaaac2d698176ee8969b195c1518a46;hb=8bc47e15da36b072924f8281688ea92935ae1c18;hp=3210bbcc83dd021a16f48ad78f7a9284ead20f21;hpb=111f774134415bb8da9b3882175603f2693026d9;p=pintos-anon

diff --git a/doc/vm.texi b/doc/vm.texi
index 3210bbc..c2943ca 100644
--- a/doc/vm.texi
+++ b/doc/vm.texi
@@ -590,16 +590,14 @@ user stack pointer.  You will need to arrange another way, such as
 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 should 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.  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
-for it to be faulted in.  (Even if you did wait, the very first
-instruction in the user program is likely to be one that faults in the
-page.)
+The first stack page need not be allocated lazily.  You can allocate
+and initialize it with the command line arguments at load time, with 
+no need to wait for it to be faulted in.
 
 All stack pages should be candidates for eviction.  An evicted stack
 page should be written to swap.
@@ -716,6 +714,12 @@ process.  If you carefully designed your data structures,
 sharing of read-only pages should not make this part significantly
 harder.
 
+@item How do we resume a process after we have handled a page fault?
+
+Returning from @func{page_fault} resumes the current user process
+(@pxref{Internal Interrupt Handling}).
+It will then retry the instruction to which the instruction pointer points.
+
 @item Does the virtual memory system need to support data segment growth?
 
 No.  The size of the data segment is determined by the linker.  We still