Only consider a disk to exist if it has nonzero size.
[pintos-anon] / doc / vm.texi
index e22b9be44aa0206984c92a5b48393dcdc9eded2f..4325b1361706de25909cab652022a2eb13a4c3ad 100644 (file)
@@ -35,6 +35,9 @@ All the test programs from the previous project should also work with
 this project.  You should also write programs to test the new features
 introduced in this project.
 
 this project.  You should also write programs to test the new features
 introduced in this project.
 
+You will continue to handle Pintos disks and file systems the same way
+you did in the previous assignment (@pxref{Using the File System}).
+
 Your submission should define @code{THREAD_JOIN_IMPLEMENTED} in
 @file{constants.h} (@pxref{Conditional Compilation}).
 
 Your submission should define @code{THREAD_JOIN_IMPLEMENTED} in
 @file{constants.h} (@pxref{Conditional Compilation}).
 
@@ -76,7 +79,7 @@ process would install its own page table into the machine.  The page
 table contained all the virtual-to-physical translations for the
 process.  Whenever the processor needed to look up a translation, it
 consulted the page table.  As long as the process only accessed
 table contained all the virtual-to-physical translations for the
 process.  Whenever the processor needed to look up a translation, it
 consulted the page table.  As long as the process only accessed
-memory that it didn't own, all was well.  If the process accessed
+memory that it owned, all was well.  If the process accessed
 memory it didn't own, it ``page faulted'' and @func{page_fault}
 terminated the process.
 
 memory it didn't own, it ``page faulted'' and @func{page_fault}
 terminated the process.
 
@@ -253,9 +256,7 @@ It is impossible to predict how large the stack will grow at compile
 time, so we must allocate pages as necessary.  You should only allocate
 additional pages if they ``appear'' to be stack accesses.  You must
 devise a heuristic that attempts to distinguish stack accesses from
 time, so we must allocate pages as necessary.  You should only allocate
 additional pages if they ``appear'' to be stack accesses.  You must
 devise a heuristic that attempts to distinguish stack accesses from
-other accesses.@footnote{You might find it useful to know that the
-80@var{x}86 instruction @code{pusha} pushes all 8 registers (32 bytes)
-on the stack at once.}  Document and explain the heuristic in your
+other accesses.  Document and explain the heuristic in your
 design documentation.
 
 The first stack page need not be loaded lazily.  You can initialize it
 design documentation.
 
 The first stack page need not be loaded lazily.  You can initialize it
@@ -376,7 +377,11 @@ is simply an outline of our suggested implementation.
 
 Implement paging to and from files and the swap disk.  You may use the
 disk on interface @code{hd1:1} as the swap disk, using the disk
 
 Implement paging to and from files and the swap disk.  You may use the
 disk on interface @code{hd1:1} as the swap disk, using the disk
-interface prototyped in @code{devices/disk.h}.
+interface prototyped in @code{devices/disk.h}.  From the @file{vm/build}
+directory, use the command @code{pintos make-disk swap.dsk @var{n}} to
+create an @var{n} MB swap disk named @file{swap.dsk}.  Afterward,
+@file{swap.dsk} will automatically be attached when you run
+@command{pintos}.
 
 You will need routines to move a page from memory to disk and from
 disk to memory, where ``disk'' is either a file or the swap disk.  If
 
 You will need routines to move a page from memory to disk and from
 disk to memory, where ``disk'' is either a file or the swap disk.  If