You will continue to handle Pintos disks and file systems the same way
you did in the previous assignment (@pxref{Using the File System}).
-The tests for project 3 (and later projects) will run much faster if
-you use the qemu emulator, e.g.@: via @code{make check
-PINTOSOPTS='--qemu'}.
-
@menu
* Project 3 Background::
* Project 3 Suggested Order of Implementation::
@node Pages
@subsubsection Pages
-A @dfn{page}, sometimes called a @dfn{virtual page}, is a contiguous
+A @dfn{page}, sometimes called a @dfn{virtual page}, is a continuous
region of virtual memory 4,096 bytes (the @dfn{page size}) in length. A
page must be @dfn{page-aligned}, that is, start on a virtual address
evenly divisible by the page size. Thus, a 32-bit virtual address can
@subsubsection Frames
A @dfn{frame}, sometimes called a @dfn{physical frame} or a @dfn{page
-frame}, is a contiguous region of physical memory. Like pages, frames
+frame}, is a continuous region of physical memory. Like pages, frames
must be page-size and page-aligned. Thus, a 32-bit physical address can
be divided into a 20-bit @dfn{frame number} and a 12-bit @dfn{frame
offset} (or just @dfn{offset}), like this:
@node Swap Slots
@subsubsection Swap Slots
-A @dfn{swap slot} is a contiguous, page-size region of disk space on the
+A @dfn{swap slot} is a continuous, page-size region of disk space on the
swap disk. Although hardware limitations dictating the placement of
slots are looser than for pages and frames, swap slots should be
page-aligned because there is no downside in doing so.