Incorporate improvements suggested by Philipp Marek.

Documentation/chap-checkpointing.tex

@@ -34,7 +34,7 @@ and only if the page has been modified since the beginning of the
 \emph{current} checkpoint cycle.  We use the word \emph{page instance}
 to refer to a particular version of a particular page. 
 
-A page can be associated with a \emph{frame}%
+A page can be associated with a \emph{frame}.%
 \footnote{A \emph{frame} is the main-memory instance of a page.}  An
 attempt to access a page that is not associated with a frame results
 in a \emph{page fault}.  At most one version of a particular page can
@@ -96,7 +96,7 @@ for version $1$.
 At any point in time, there exist three version tables; two on disk
 and one in main memory.  The two versions on disk play the same role
 as the disk tables in EROS, i.e., while one of them is being updated,
-the other is till complete and accurate.  A single bit in the boot
+the other is still complete and accurate.  A single bit in the boot
 sector of the disk selects which one should be used at boot time.
 When a new version table needs to be written to disk, it is first
 written to the place of the unused disk table, and then the boot
@@ -138,7 +138,7 @@ version table directory is scanned.  Whenever a directory entry with
 the bit indicating the existence of pages with several versions set,
 the page of the directory entry is saved to disk.  When the entire
 version table has been scanned, a new boot sector is written
-indicating that the newly saved table is the current one.
+to indicate that the newly saved table is the current one.
 
 The final action to take in order to finish the current checkpointing
 cycle and begin a new one is an \emph{atomic flip}.  This atomic flip

Documentation/chap-device-drivers.tex

@@ -59,7 +59,8 @@ This class is an instantiable subclass of the class \texttt{disk}.
 
 \Defgeneric {size} {disk}
 
-Return the number of blocks that \textit{disk} may store.
+Return the number of blocks that \textit{disk} may store, so excluding
+bad blocks.
 
 \Defgeneric {block-size} {disk}
 

Documentation/chap-environments.tex

@@ -84,7 +84,7 @@ When we say that a method is \emph{linked} to the current global
 environment, we just mean that references to symbols within that
 method are resolved in the current global environment.  
 
-This mechanism provides an efficient method of protection.  A user A
+This mechanism provides an efficient method of protection.  User A
 can grant controlled access to part of his or her global environment
 by allowing a user B to execute a function made available to him or
 her through the \emph{object store}.  \seechap{chap-object-store} In a

Documentation/chap-intro.tex

@@ -73,8 +73,8 @@ components to be modified.
 \end{itemize}
 
 Pipes also have some advantages though.  In particular, they provide a
-\emph{synchronization} mechanism between programs, making very easy to
-implement producer/consumer control structures.
+\emph{synchronization} mechanism between programs, making it very easy
+to implement producer/consumer control structures.
 
 It is an interesting observation that in most text books on
 operating systems, the concept of a process is presented as playing
@@ -126,7 +126,7 @@ transformed into an in-memory structure.
 
 \subsection{Distinction between primary and secondary memory}
 
-Current system (at least for desktop computers) make a very clear
+Current systems (at least for desktop computers) make a very clear
 distinction between primary and secondary memory.  Not only are the
 two not the same, but they also have totally different semantics:
 \begin{itemize}
@@ -169,9 +169,9 @@ computers with no memory-management unit.
 
 Full address-space access is a notorious source of security problems.
 If a program does not take great care to prevent a temporary buffer
-from overflowing, reading an external document such as web page may
+from overflowing, reading an external document such as a web page may
 overwrite part of the stack (which is located in the address space of
-the process).  Such buffer overflow can alter the return address of
+the process).  Such a buffer overflow can alter the return address of
 the currently executing function, so that instead of returning
 normally, it returns to some code that can have an effect that the
 program was absolutely not meant to have.  It can do that because the
@@ -197,15 +197,15 @@ structures with absolute virtual address at start-up.  Either relative
 addressing must be used (which complicates the code and thus makes it
 less maintainable), or such data structures must use symbolic
 addresses to be resolved by the dynamic linker at program start-up
-(which also complicates the code, but also slows down program start-up
-because of additional work that the linker must do).
+(which also complicates the code, but in addition slows down program
+start-up because of additional work that the linker must do).
 
 \subsection{The concept of a kernel}
 
 The kernel of an operating system is a fairly large, monolithic
 program that is started when the computer is powered on. The kernel is
 not an ordinary program of the computer. It executes in a privileged
-state so that it has direct access to devices and to data structures
+state so that it has full access to devices and to data structures
 that must be protected from direct use by user-level programs.
 
 The very existence of a kernel is problematic because the computer
@@ -215,12 +215,12 @@ reside in volatile memory. Some programs, such as web browsers,
 compensate somewhat for this problem by remembering the open windows
 and the links that were associated with each window.
 
-The fact that the kernel is monolithic poses a problem because when
+The fact that the kernel is monolithic poses a problem; because, when
 code needs to be added to the kernel in the form of a kernel module,
 such code has full access to the entire computer system. This
 universal access represents a security risk, of course, but more
-commonly, it can be defective and then it will fail often by crashing
-the entire computer.
+commonly, the module can be defective and then it will fail often by
+crashing the entire computer.
 
 The problem with traditional kernels compared to the planned LispOS
 described in this document is similar to the difference between an
@@ -253,7 +253,7 @@ request would crash.
 \section{Objectives for a Lisp operating system}
 
 The three main objectives of a Lisp operating system correspond to
-solutions to the two main problems with exiting systems as indicated
+solutions to the two main problems with existing systems as indicated
 in the previous section.
 
 \subsection{Single address space}
@@ -346,7 +346,7 @@ algorithms.
 \subsubsection{Crash proof (maybe)}
 
 There is extensive work on crash-proof systems, be it operating
-systems or data base systems.  In our opinion, this work is
+systems or database systems.  In our opinion, this work is
 confusing in that the objective is not clearly stated.
 
 Sometimes the objective is stated as the desire that no data be lost
@@ -357,7 +357,7 @@ controlled way.
 
 Other times, the objective is stated as a protection against
 defective software, so that data is stored at regular intervals
-(checkpointing) perhaps combined with a \emph{transaction log} so
+(checkpointing), perhaps combined with a \emph{transaction log} so
 that the state of the system immediately before a crash can always
 be recovered.  But it is very hard to protect oneself against
 defective software.  There can be defects in the checkpointing code
@@ -448,8 +448,8 @@ interface libraries, etc. for the system.
 \subsection{Create a multi-user system as a \unix{} process}
 
 With the new \commonlisp{} system complete and the object store implemented,
-it will be possible to create a full multi-user system, including
-protection, as a \unix{} process, where the \unix{} system would play
+it will be possible to create a full multi-user system (including
+protection) as a \unix{} process, where the \unix{} system would play
 the role of a virtual machine, supplying essential services such as
 input/output, networking, etc. 
 

Documentation/chap-object-store.tex

@@ -14,7 +14,7 @@ attribute value can be any object.
 {|>{\setlength\hsize{.2\hsize}}X|%
   >{\setlength\hsize{.8\hsize}}X|}
 \hline
-Keyword & Possible-values\\
+Keyword & Possible values\\
 \hline\hline
 \textbf{category} &
 
@@ -46,21 +46,13 @@ chosen from an editable set that is defined per user.\\
 \textbf{format} &
 
 This attribute can be used to identify the file type of documents such
-as \textbf{PDF}, \textbf{ogg/vorbis}, \textbf{MPEG4} \textbf{PNG}, in
+as \textbf{PDF}, \textbf{ogg/vorbis}, \textbf{MPEG4}, \textbf{PNG}, in
 which case the attribute can be assigned automatically, but also to
 identify the source format of files in a directory containing
 things like articles or user manuals, for
 example \textbf{LaTeX}, \textbf{Texinfo}, \textbf{HTML}.  These would
 be chosen from an editable set that is defined per user. \\
 \hline
-\end{tabularx}
-
-\begin{tabularx}{\linewidth}%
-{|>{\setlength\hsize{.2\hsize}}X|%
-  >{\setlength\hsize{.8\hsize}}X|}
-\hline
-Keyword & Possible-values\\
-\hline\hline
 \textbf{date of creation} &
 
 A date interval.\\
@@ -94,18 +86,18 @@ would be chosen from an editable set that is defined per user.\\
 
 In a typical operating system installation, there are many fairly
 large objects such as movies, music files, pictures, etc.  The amount
-data associated with such an object that would be stored in the object
-store is typically very small compared to the object itself.  Even a
-fairly modest text file probably has $10^4 - 10^5$ characters in it,
-whereas the meta-data probably takes up no more than $10^2 - 10^3$
-bytes.  It is therefore likely that the entire object store will fit
-in main memory.  Scanning the entire object store would then take at
-most a few second of CPU time.  For better performance, one or more
+of data associated with such an object that would be stored in the
+object store is typically very small compared to the object itself.
+Even a fairly modest text file probably has $10^4 - 10^5$ characters
+in it, whereas the meta-data probably takes up no more than $10^2 -
+10^3$ bytes.  It is therefore likely that the entire object store will
+fit in main memory.  Scanning the entire object store would then take
+at most a few second of CPU time.  For better performance, one or more
 \emph{indexes} could be created.  The objects could for instance be
 divided by \emph{category}.
 
 Searching the object store amounts to defining a \emph{filter},
-i.e. a function that, given a set of keyword/value pairs returns
+i.e. a function that, given a set of keyword/value pairs, returns
 \emph{true} if and only if the corresponding object should be included
 in the search result.  The result is returned to the user in the form
 of a \emph{directory object} which is a list of \emph{object entries}

Documentation/chap-protection.tex

@@ -5,7 +5,7 @@ There are two kinds of protection that are important in an operating
 system:
 
 \begin{itemize}
-\item \emph{protecting different users from each other}.  A user A
+\item \emph{protecting different users from each other}.  User A
   should not be able to access or destroy the data of some other user
   B, other than if B explicitly permits it, and then only in ways that
   are acceptable to B.