process george's comments
[msc-thesis1617.git] / results.arch.tex
index cd9918d..f4b615a 100644 (file)
@@ -1,14 +1,13 @@
-\section{Architecture}
-\subsection{Devices}
+\section{Devices}
 The client code for the devices is compiled from one codebase. For a device to
-be eligible for \glspl{mTask} it must be able to compile the shared codebase
+be eligible for \glspl{mTask}, it must be able to compile the shared codebase
 and implement (part of) the device specific interface. The shared codebase only
 uses standard \gls{C} and no special libraries or tricks are used. Therefore
 the code is compilable for almost any device or system. Note that it is not
-needed to implement a full interface. The full interface excluding the device
-specific settings is listed in Appendix~\ref{app:device-interface}. The
-interface works in a similar fashion as the \gls{EDSL}. Devices do not have to
-implement all functionality, this is analogous to the fact that views do not
+needed to implement a full interface. The full interface --- excluding the
+device specific settings --- is listed in Appendix~\ref{app:device-interface}.
+The interface works in a similar fashion as the \gls{EDSL}. Devices do not have
+to implement all functionality, this is analogous to the fact that views do not
 have to implement all type classes in the \gls{EDSL}.  When the device connects
 for the first time with a server the specifications of what is implemented is
 communicated.
@@ -32,7 +31,7 @@ the device software.
                board that only boasts a meager \emph{2K} of \emph{RAM}.
 \end{itemize}
 
-\subsection{Specification}
+\section{Specification}
 Devices are stored in a record type and all devices in the system are stored in
 a \gls{SDS} containing all devices. From the macro settings in the interface
 file a profile is created for the device that describes the specification. When
@@ -51,16 +50,13 @@ of. The exact specification is listed in Listing~\ref{lst:devicespec}
        }
 \end{lstlisting}
 
-\subsection{Memory Management}
-\todo{Explain specification, combine task and share space}
-
-\subsection{Communication}
+\section{Communication}
 The communication to and fro a device runs via a single \gls{SDS}. Every
 device has a specific resource that is used to connect to the device. The
 current system supports connecting devices via a serial connection and via a
 \gls{TCP} connection. Every device has the type \CI{MTaskDevice} and which
-is listed in Listing~\ref{lst:mtaskdevice}. When a device is added a background
-task is started that runs the \CI{synFun}. The \CI{synFun} is the task that
+is listed in Listing~\ref{lst:mtaskdevice}. When a device is added, a background
+\gls{Task} is started that runs the \CI{synFun}. The \CI{synFun} is the task that
 synchronizes the channel \gls{SDS} with the actual device. For the \gls{TCP}
 device this is a simple \CI{tcpconnect}. The \CI{TaskId} of the background task
 is saved to be able to stop the task in the future. When the task is unable to
@@ -80,6 +76,7 @@ connect it will set the \CI{deviceError} field to notify the user.
                , deviceTasks :: [MTaskTask]
                , deviceData :: MTaskResource
                , deviceSpec :: Maybe MTaskDeviceSpec
+               , deviceShares :: [MTaskShare]
        }
 
 class MTaskDuplex a where