Fixed compile errors when building all as PDFs
authorKyle Spaans <kspaans@student.math.uwaterloo.ca>
Thu, 9 Jul 2009 02:00:48 +0000 (22:00 -0400)
committerKyle Spaans <kspaans@student.math.uwaterloo.ca>
Thu, 9 Jul 2009 02:00:48 +0000 (22:00 -0400)
lec11-0609.tex
lec13-0618.tex
lec17-0702.tex

index 79c8a89..7f7bf8d 100644 (file)
@@ -39,7 +39,7 @@ as making segments visible to user applications. A segment can be mapped to a
 physical chunk of memory, and we'll need a segment table, just like with pages.
 The number of bits corresponding to the segment number will indicate the
 number of segments that the system has. Segments will have a max size of
-$2^{\mathrm{# offset bits}}$. Thus we only need to allocate smaller segment
+$2^{\mathrm{\# offset bits}}$. Thus we only need to allocate smaller segment
 tables instead of large page tables.
 
 \subsection*{Combinig Segments and Paging}
index 448e8f9..1c004eb 100644 (file)
@@ -25,6 +25,7 @@ First, some quick notes relevant to the assignment:
       And recall that the new thread/process created by \texttt{fork()} will
       never has been in usermode before, so we need to put it there by having
       it run the \texttt{md\_forkentry()} function.
+\end{itemize}
 
 \subsection*{\texttt{execv()}}
 When the new address space is initialized, remember that we only need to touch
index c3dd492..9934fcd 100644 (file)
@@ -28,7 +28,7 @@ Since the programs will only touch a small number of pages within their address
 spaces, they should be able to work. There are tests specifically for this. We
 will also implement a page freer so that \emph{OS161} won't crash all the time.
 It should be able to reclaim pages that have been entirely freed (E.G. when a
-thread terminates). The \textt{kfree()} already handles allocation and freeing
+thread terminates). The \texttt{kfree()} already handles allocation and freeing
 within subpages, but once a whole page it touched, the kernel does not try to
 reclaim it. It will be a \textbf{physical memory manager}.