glossery: introduce some first-use items

This requires the usage of \glsentrytext in chapters etc., because the
first expansion shouldn't happen there.

src/docs/glossary.tex

@@ -1,41 +1,60 @@
 % // vim: set ft=tex:
 
-\newglossaryentry{Rust}{
+\newglossaryentry{Rust} {
-    name=Rust
+    name = {Rust},
-    , description={
+    long = {the Rust programming language},
-        TODO programming language
+    description = {
-    }
+        Statically typed programming language that uses a new concept of variable ownership and reference tracking. Largely explain in \autoref{context::rust}.
+    },
+    first = {\glsentrylong{Rust}}
 }
 
+\newglossaryentry{proglang} {
+    name = {programming language},
+    description = {
+        A well-defined language used to write software. Hundreds of language exists, each with focus on different aspects like comfort for humans, size, speed, safety, etc.
+    },
+}
+
+
 \newglossaryentry{compiler}{
     name = compiler,
+    long = {source- to machine-code compiler},
     description = {
         A program that can transform software source code to executable machine code.
+        Typically targetted for a \glsentryname{proglang} or a family of \glspl{proglang}.
     },
+    first = {\glsentrylong{compiler}}
 }
 
 \newglossaryentry{addrspace}{
-    name = memory address space,
+    name = address space,
+    long = bound address range in memory,
     description = {
-        A logical entity that represents parts of the virtual memory, specified with a starting address and the length in a standardize unit
+        A logical entity that represents a section of memory, specified with a start address and either by end address or length given in a standardize unit
     },
+    first = {\glsentrylong{addrspace}}
 }
 
-\newglossaryentry{API}{
+\newglossaryentry{api}{
     name = API,
+    long = {Application Programming Interface},
     description = {
-        Application Programming Interface
     },
+    first = {\glsentrylong{api}}
 }
 
 \newglossaryentry{OS}{
-    name = Operating System,
+    name = OS,
+    long = Operating System,
     description = {
         The software that manages the system's hardware ressources.
         Other \glspl{app} can access the ressources only through the interface provided by the \gls{OS}.
     },
+    first = {\glsentrylong{OS}}
 }
 
+
 \newglossaryentry{fs}{
     name = filesystem,
     description = {

src/docs/parts/context/context.tex

@@ -2,7 +2,7 @@
 \chapter{Introduction}
 \label{context::introduction}
 
-This thesis studies the feasibility of using compile-time code analysis, as found in the \gls{Rust} \gls{compiler}, for ensuring memory-safety within an \gls{OS} kernel.
+This thesis studies the feasibility of using compile-time code analysis, as found in \gls{Rust}'s \gls{compiler}, for ensuring memory-safety within an \gls{OS} kernel.
 Because an \gls{OS} is nothing but a \gls{app}, this study could be applied to all \glspl{app}, but the focus is on the implementation of \glspl{OS} which is the \gls{app} that is responsible for managing the system's resources and provide abstractions for higher level applications.
 The \gls{OS} is the only \gls{app} that required unrestricted access to these resources, with the task of managing them safely according to the rules that are either hard-coded or set up by the \gls{sysadmin}.
 
@@ -27,7 +27,7 @@ The execution of other programs is potentially dangerous, because the program mi
 It is the responsibility of the \gls{OS} to prevent programs from being able to interfere with each other under any circumstances, keeping the memory content in a consistent state at all times.
 This requires an extensive amount of care and foresight from the developers of the \gls{OS}, to ensure memory consistency in any of the various events and combinations thereof that might possibly occur at runtime.
 
-\subsection{A Definition Of Memory-Safety}
+\subsection{A Definition Of Memory-Safety in the \glsentrytext{OS}}
 \label{context::introduction::memory-safety::def}
 If the \gls{OS} is memory-safe, any program, whether it is part of the \gls{OS} or any other \gls{app}, memory access is restricted to memory regions that have been allocated for this specific program, preventing it from reading and writing to memory regions of other programs.
 
@@ -74,7 +74,7 @@ In addition, the language can introduce obligated rules that make the written pr
 In \autoref{context::introduction::memory-safety}, specifically in \autoref{context::introduction::memory-safety::detection}, it was explained that programming languages have direct impact on the memory-safety.
 This section gives an example of how severe this impact is and explains the requirements on a \gls{OS} language.
 
-\subsection{\gls{Linux} and \gls{C}: Zero Memory-Safety A Day}
+\subsection{\glsentrytext{Linux} and \glsentrytext{C}: Zero Memory-Safety A Day}
 % Significance of the Study
 % The significance is a statement of why it is important to determine the answer to the gap in the knowledge, and is related to improving the human condition. The contribution to the body of knowledge is described, and summarizes who will be able to use the knowledge to make better decisions, improve policy, advance science, or other uses of the new information. The “new” data is the information used to fill the gap in the knowledge.
 A very popular and widespread \gls{OS} is \gls{Linux} which is written in \gls{C} and some hardware specific \gls{asm} code.
@@ -91,8 +91,8 @@ This has been forcing \gls{OS} developers to prioritize performance over safety.
 
 Details about the challenge of writing code that does memory management safely, and related vulnerabilities are given further along in \autoref{chap:mmt}.
 
-\subsection{\gls{OS} Language Choices}
+\subsection{\glsentrytext{OS} Programming Language Choice}
-Criteria for the choice of language are much different from choosing a language for other types of \glspl{app}.
+Criteria for the choice of programming language are much different from choosing a language for other types of \glspl{app}.
 
 This is a list of what is required for implementing an \glspl{OS}
 
@@ -245,12 +245,16 @@ As per the previous \autoref{chap:context.mem-weaknesses} there is general aware
 * TODO: deadlock example
 
 \chapter{Introduction To Rust}
+\label{context::rust}
+Described by the maintainers, it is a "systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety.", (www.rust-lang.org)
 
 \section{Compiler Architecture}
 - TODO: Tokens? AST? LLVM? (http://embed.rs/articles/2016/arm-inline-assembly-rust/)
 - TODO: BSYS SS17 GITHUB IO Rust Memory Layout - 4
 
-\section{Static Analysis Features}
+\subsection{Static Analyser}
+
+\section{Language Features}
 - TODO: How does static typing help with preventing programming errors
 - TODO: How does the Rust's static analysis work, theoretically and practically
 - TODO: How can memory be dynamically allocated and still safety checked?
@@ -258,7 +262,6 @@ As per the previous \autoref{chap:context.mem-weaknesses} there is general aware
 \subsection{Ownership And Borrows}
 - TODO: Who owns global 'static variables?
 
-- https://nercury.github.io/rust/guide/2015/01/19/ownership.html
 
 \subsection{Lifetimes}
 - TODO: Where are global 'static variables allocated?
@@ -268,19 +271,21 @@ As per the previous \autoref{chap:context.mem-weaknesses} there is general aware
 - TODO: demonstrate raw pointers
 - TODO: what's the equivalent of void*?
 
-\subsection{The Newtype Pattern}
+\subsection{Inner- and Outer Mutability}
+- TODO: describe Rc, Arc, and {Ref,}Cell
+
+- https://nercury.github.io/rust/guide/2015/01/19/ownership.html
 
 \subsection{Zero-Cost Abstraction}
 
-
+\section{Language Extension}
-https://aturon.github.io/features/types/newtype.html
-
-
-\subsection{Im/mutability}
-- TODO: describe Rc, Arc, and {Ref,}Cell
-
-\section Language Extension
 \subsection{Syntax Extension}
 \subsubsection{Macros}
 \subsubsection{Annotations}
 \subsection{Compiler Plugins}
+
+\section{Idioms And Patterns}
+
+\subsection{The Newtype Pattern}
+https://aturon.github.io/features/types/newtype.html
+

src/docs/parts/research_and_development/research_and_development.tex

@@ -29,11 +29,10 @@ Guarantees to be statically checked:
 * TODO: describe that tests are mostly semantics as opposed to static checks being mostly syntactical and technical
 * TODO: They necessary in addition to static checks to cover the well-known use-cases and edge-cases. TODO: example?
 
-\chapter{Attempt Extend \gls{Linux} with \gls{Rust}}
+\chapter{\glsentrytext{Linux} Modules Written In \glsentrytext{Rust}}
 * TODO: describe Difficulties with the GPL Macros used Within Kernel Modules
 
-\chapter{Existing \gls{OS}-Development Projects Based On Rust}
+\chapter{Existing \glsentrytext{OS}-Development Projects Based On Rust}
-
 
 \section{Libraries}
 
@@ -46,7 +45,7 @@ Guarantees to be statically checked:
 \subsection{Redox}
 \subsection{Tock}
 
-\chapter{\gls{imezzos}: Adding Preemptive \gls{OS}-Level Multitasking}
+\chapter{\glsentrytext{imezzos}: Adding Preemptive \glsentrytext{OS}-Level Multitasking}
 
 \section{Timed Interrupts For Scheduling and Dispatching}
 \section{Simple Stack Allocation Scheme}

src/docs/thesis.tex

@@ -37,7 +37,7 @@
 \newcommand{\supervisorTwo}{Felix Schuckert}
 \newcommand{\studies}{Master Information Technology - Embedded And Mobile Systems}
 \newcommand{\startdate}{2017/4/1}
-\newcommand{\submitdate}{2017/8/31}
+\newcommand{\submitdate}{2017/9/29}
 \newcommand{\buzzwords}{memory-safety, operating system, rust}
 
 % Numbered Subsubsections
@@ -121,6 +121,7 @@
 
 \pagestyle{main}
 	%TODO \include{acknowledgments}
+    %TODO abstract
 
     \chapter*{Preface}
     This thesis is original, unpublished, independent work by the author, \authorOne.