From db5f64e2a8270400c79539f71b6e3e614f7827e1 Mon Sep 17 00:00:00 2001 From: Robert Strandh Date: Sat, 18 Feb 2017 07:03:03 +0100 Subject: [PATCH] Incorporate improvements suggested by Philipp Marek. --- Documentation/chap-checkpointing.tex | 6 ++--- Documentation/chap-device-drivers.tex | 3 ++- Documentation/chap-environments.tex | 2 +- Documentation/chap-intro.tex | 32 +++++++++++++-------------- Documentation/chap-object-store.tex | 28 +++++++++-------------- Documentation/chap-protection.tex | 2 +- 6 files changed, 33 insertions(+), 40 deletions(-) diff --git a/Documentation/chap-checkpointing.tex b/Documentation/chap-checkpointing.tex index e4ad2e8..7673132 100644 --- a/Documentation/chap-checkpointing.tex +++ b/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 diff --git a/Documentation/chap-device-drivers.tex b/Documentation/chap-device-drivers.tex index bd252ae..682d5a1 100644 --- a/Documentation/chap-device-drivers.tex +++ b/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} diff --git a/Documentation/chap-environments.tex b/Documentation/chap-environments.tex index 5c11fbf..69752c7 100644 --- a/Documentation/chap-environments.tex +++ b/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 diff --git a/Documentation/chap-intro.tex b/Documentation/chap-intro.tex index 4557ba4..352982b 100644 --- a/Documentation/chap-intro.tex +++ b/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. diff --git a/Documentation/chap-object-store.tex b/Documentation/chap-object-store.tex index 343f7ab..b1bcff3 100644 --- a/Documentation/chap-object-store.tex +++ b/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} diff --git a/Documentation/chap-protection.tex b/Documentation/chap-protection.tex index 373cce3..d70afe4 100644 --- a/Documentation/chap-protection.tex +++ b/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.