X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=doc%2Fvm.texi;h=2fe66532ae81ff607fdb824b5833fd02ec49139a;hb=60a942524737a1053d8b980bfc4e403ea8ec0007;hp=8afc49c53d6f9a17665c6f3e22469fa89f8b3dfb;hpb=854bff58300995947f3e0a5083e382506d799890;p=pintos-anon

diff --git a/doc/vm.texi b/doc/vm.texi
index 8afc49c..2fe6653 100644
--- a/doc/vm.texi
+++ b/doc/vm.texi
@@ -316,12 +316,12 @@ Some way of translating in software from virtual page frames to
 physical page frames.  Pintos provides a hash table that you may find
 useful for this purpose (@pxref{Hash Table}).
 
-It is possible to do this translation without adding a new data
-structure, by modifying the code in @file{userprog/pagedir.c}.  However,
-if you do that you'll need to carefully study and understand section
-3.7, ``Page Translation Using 32-Bit Physical Addressing,'' in
-@bibref{IA32-v3a}, and in practice it is probably easier to add a new
-data structure.
+You don't strictly need a new data structure for this.  You could
+instead modify the code in @file{userprog/pagedir.c}.  If you do that
+you'll need to thoroughly understand how 80@var{x}86 page tables work
+by, e.g.,@: studying section 3.7, ``Page Translation Using 32-Bit
+Physical Addressing,'' in @bibref{IA32-v3a}.  In practice, most groups
+use a separate data structure.
 
 @item
 Some way of finding a page on disk (in a file or in swap) if it is not
@@ -420,11 +420,10 @@ Bits}) to implement an approximation to LRU.  Your algorithm should
 perform at least as well as the ``second chance'' or ``clock''
 algorithm.
 
-Your design should allow for parallelism.  Multiple processes should
-be able to process page faults at once.  If one page fault require
+Your design should allow for parallelism.  If one page fault requires
 I/O, in the meantime processes that do not fault should continue
-executing and other page faults that do not require I/O should be able to
-complete.  These criteria require some synchronization effort.
+executing and other page faults that do not require I/O should be able
+to complete.  These criteria require some synchronization effort.
 
 @node Lazy Loading
 @subsection Lazy Loading
@@ -441,25 +440,25 @@ be written to swap.
 
 The core of the program loader is the loop in @func{load_segment} in
 @file{userprog/process.c}.
-Each time around the loop, @code{read_bytes} receives the number of
-bytes to read from the executable file and @code{zero_bytes} receives
+Each time around the loop, @code{page_read_bytes} receives the number of
+bytes to read from the executable file and @code{page_zero_bytes} receives
 the number of bytes to initialize to zero following the bytes read.  The
 two always sum to @code{PGSIZE} (4,096).  The handling of a page depends
 on these variables' values:
 
 @itemize @bullet
 @item
-If @code{read_bytes} equals @code{PGSIZE}, the page should be demand
+If @code{page_read_bytes} equals @code{PGSIZE}, the page should be demand
 paged from disk on its first access.
 
 @item
-If @code{zero_bytes} equals @code{PGSIZE}, the page does not need to
+If @code{page_zero_bytes} equals @code{PGSIZE}, the page does not need to
 be read from disk at all because it is all zeroes.  You should handle
 such pages by creating a new page consisting of all zeroes at the
 first page fault.
 
 @item
-If neither @code{read_bytes} nor @code{zero_bytes} equals
+If neither @code{page_read_bytes} nor @code{page_zero_bytes} equals
 @code{PGSIZE}, then part of the page is to be read from disk and the
 remainder zeroed.  This is a special case.  You are allowed to handle
 it by reading the partial page from disk at executable load time and
@@ -535,6 +534,11 @@ Maps the file open as @var{fd} into the process's virtual address
 space.  The entire file is mapped into consecutive virtual pages
 starting at @var{addr}.
 
+Your VM system must lazily load pages in @code{mmap} regions and use the
+@code{mmap}'d file itself as backing store for the mapping.  That is,
+evicting a page mapped by @code{mmap} writes it back to the file it was
+mapped from.
+
 If the file's length is not a multiple of @code{PGSIZE}, then some
 bytes in the final mapped page ``stick out'' beyond the end of the
 file.  Set these bytes to zero when the page is faulted in from disk,
@@ -554,12 +558,6 @@ pages, including the stack or pages mapped at executable load time.
 It must also fail if @var{addr} is 0, because some Pintos code assumes
 virtual page 0 is not mapped.  Finally, file descriptors 0 and 1,
 representing console input and output, are not mappable.
-
-Your VM system should use the @code{mmap}'d file itself as backing
-store for the mapping.  That is, to evict a page mapped by
-@code{mmap}, write it to the file it was mapped from.  (In fact, you
-may choose to implement executable mappings as special, copy-on-write
-file mappings.)
 @end deftypefn
 
 @deftypefn {System Call} void munmap (mapid_t @var{mapping})