More minor bug fixes and improvements.

Documentation/chap-environments.tex

@@ -42,12 +42,12 @@ still refer to the environment into which it was compiled or loaded.
 This mechanism provides an efficient method of protection.  A 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 traditional modern operating system such as Unix, this kind of
+her through the \emph{object store}.  \seechap{chap-object-store} In a
+traditional modern operating system such as \unix{}, this kind of
 controlled access required the use of the \emph{setuid} mechanism,
 simply because in such a system there is no way to access an object
 other than through the global file system, and the accessing user must
-have the right permissions to access the object. 
+have the right permissions to access the object.
 
 The same mechanism can be used by the system itself to protect objects
 that would be unwise to give users direct access to, such as disks or

Documentation/chap-intro.tex

@@ -284,32 +284,40 @@ The most important aspect of a Lisp operating system is not that all
 the code be written in Lisp, but rather to present a Lisp-like
 interface between users and the system and between applications and
 the system.  It is therefore legitimate to take advantage of some
-existing system (probably Linux or some BSD version) in order to
-provide services such as device drivers, network communication,
-thread scheduling, etc. 
+existing system (probably \linux{} or some \bsd{} version) in order to
+provide services such as device drivers, network communication, thread
+scheduling, etc.
 
 \subsection{Create a Lisp system to be used as basis}
 
-The first step is to create a Common Lisp system that can be used as
-a basis for the Lisp operating system.  It should already allow for
-multiple environments, and it should be available on 64-bit
-platforms.  Preferably, this system should use as little C code as
-possible and interact directly with the system calls of the
-underlying kernel.
+The first step is to create a \cl{} system that can be used as a basis
+for the Lisp operating system.  It should already allow for multiple
+environments, and it should be available on 64-bit platforms.
+Preferably, this system should use as little \clanguage{} code as
+possible and interact directly with the system calls of the underlying
+kernel.
 
 \subsection{Create a single-user system as a \unix{} process}
 
-The next step is to transform the Common Lisp system into an
-operating system in the sense of the API for users and
-applications.  This system would contain the object store, but
-perhaps not access control functionality.
+In parallel with creating a new \cl{} system, it is possible to
+implement and test many of the features of the interface between the
+system and the users, such as the object store (probably without
+access control) using an existing \cl{} system running as a process in
+an ordinary operating system.  
 
-When this step is accomplished, it is possible to write or adapt
-applications such as text editors, inspectors, debuggers, GUI
+The result of this activity would be sufficient to write or adapt
+several applications such as text editors, inspectors, debuggers, GUI
 interface libraries, etc. for the system.
 
+\subsection{Create a multi-user system as a \unix{} process}
+
+With the new \cl{} 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
+the role of a virtual machine, supplying essential services such as
+input/output, networking, etc. 
+
 \subsection{Create device drivers}
 
 The final step is to replace the temporary \unix{} kernel with native
-device drivers for the new system and to turn the system into a full
-multi-user operating system.
+device drivers for the new system.

Documentation/chap-object-store.tex

@@ -96,8 +96,8 @@ 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$
+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

Documentation/chap-protection.tex

@@ -39,14 +39,13 @@ method).
 
 The access bits of a capability are determined when the object is
 accessed through the object store.  \seechap{chap-object-store} One of
-the possible key/value pairs associated with the object in the object
-store corresponds to the access permissions in the form of an
-\emph{access control list}.  A user who accesses the object from the
-object store will be checked against the access control list and
-appropriate access bits will be added to the object before it is given
-to the user.  
+the possible attributes associated with the object in the object store
+corresponds to the access permissions in the form of an \emph{access
+  control list}.  A user who accesses the object from the object store
+will be checked against the access control list and appropriate access
+bits will be cleared in the object before it is given to the user.
 
-\section{Protecting system from the users}
+\section{Protecting the system from the users}
 
 In a typical modern operating system, the system is protected from the
 users through the use of a \emph{mode} of execution of the processor,
@@ -72,7 +71,7 @@ its own \emph{address space}, which means that it can not directly
 manipulate \sysname{} capabilities.  Instead, it has to communicate
 with the system through the user of \emph{system calls}.  A
 system-wide object is referred to by such code through an interposing
-\emph{object descriptor}, much like a file descriptor in Unix.  The
-details of this mechanism have not yet been fully determined. 
+\emph{object descriptor}, much like a file descriptor in \unix{}.  The
+details of this mechanism have not yet been fully determined.