executing and other page faults that do not require I/O should be able to
complete. These criteria require some synchronization effort.
-Write your code so that we can choose a page replacement policy at
-Pintos startup time. By default, the LRU-like algorithm must be in
-effect, but we must be able to choose random replacement by invoking
-@command{pintos} with the @option{-rndpg} option. Passing this option
-sets @code{enable_random_paging}, declared in @file{threads/init.h}, to
-true.
-
@node Lazy Loading
@subsection Lazy Loading
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,
and discard them when the page is written back to disk.
+A partial page need not be lazily loaded, as in the case of a partial
+page in an executable (@pxref{Lazy Loading}).
If successful, this function returns a ``mapping ID'' that
uniquely identifies the mapping within the process. On failure,
written back to the file, and pages not written must not be. The pages
are then removed from the process's list of virtual pages.
+If two or more processes map the same file, there is no requirement that
+they see consistent data. Unix handles this by making the two mappings
+share the same physical page, but the @code{mmap} system call also has
+an argument allowing the client to specify whether the page is shared or
+private (i.e.@: copy-on-write).
+
@node Project 3 FAQ
@section FAQ
munmap (map);
@end example
-@item What if two processes map the same file into memory?
-
-There is no requirement in Pintos that the two processes see
-consistent data. Unix handles this by making the two mappings share the
-same physical page, but the @code{mmap} system call also has an
-argument allowing the client to specify whether the page is shared or
-private (i.e.@: copy-on-write).
+The @command{mcp} program in @file{src/examples} shows how to copy a
+file using memory-mapped I/O.
@item What happens if a user removes a @code{mmap}'d file?