file or swap. You will have to implement a more sophisticated page
fault handler to handle these cases. Your page fault handler, which you
should implement by modifying @func{page_fault} in
-@file{threads/exception.c}, needs to do roughly the following:
+@file{userprog/exception.c}, needs to do roughly the following:
@enumerate 1
@item
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.
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