From: Ben Pfaff Date: Mon, 17 Mar 2008 11:56:48 +0000 (+0000) Subject: Wording improvements, from "Valentin I. Spitkovsky" X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=401069bc9a5b60287a21798f8a69c2f1c84dcba7;p=pintos-anon Wording improvements, from "Valentin I. Spitkovsky" . --- diff --git a/doc/filesys.texi b/doc/filesys.texi index 9ed836a..2567d6a 100644 --- a/doc/filesys.texi +++ b/doc/filesys.texi @@ -112,8 +112,8 @@ for test @var{t} is named @file{@var{t}.tar}. @node Project 4 Suggested Order of Implementation @section Suggested Order of Implementation -We suggest implementing the parts of this project in the following -order to make your job easier: +To make your job easier, we suggest implementing the parts of this +project in the following order: @enumerate @item @@ -314,7 +314,7 @@ extra effort on your part. Modify the file system to keep a cache of file blocks. When a request is made to read or write a block, check to see if it is in the cache, and if so, use the cached data without going to -disk. Otherwise, fetch the block from disk into cache, evicting an +disk. Otherwise, fetch the block from disk into the cache, evicting an older entry if necessary. You are limited to a cache no greater than 64 sectors in size. @@ -519,7 +519,7 @@ corresponding sector from disk when it's created. Keeping extra copies of inodes would subvert the 64-block limitation that we place on your cache. -You can store a pointer to inode data in @struct{inode}, but it you do +You can store a pointer to inode data in @struct{inode}, but if you do so you should carefully make sure that this does not limit your OS to 64 simultaneously open files. You can also store other information to help you find the inode when you diff --git a/doc/vm.texi b/doc/vm.texi index 31a8f1e..fdbc5c6 100644 --- a/doc/vm.texi +++ b/doc/vm.texi @@ -576,7 +576,7 @@ bytes below the stack pointer. You will need to be able to obtain the current value of the user program's stack pointer. Within a system call or a page fault generated -by a user program, you can retrieve it from @code{esp} member of the +by a user program, you can retrieve it from the @code{esp} member of the @struct{intr_frame} passed to @func{syscall_handler} or @func{page_fault}, respectively. If you verify user pointers before accessing them (@pxref{Accessing User Memory}), these are the only cases @@ -613,7 +613,7 @@ 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, +@code{mmap}ed 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.