%*
%* Copyright (c) 2007 by Lukas Ruf (lukas.ruf@lpr.ch)
%*
%* Create: 2007-01-30:1636
%* Modify: 2007-01-30:1643
%* Commit: $Id: results.tex 272 2007-03-06 21:45:29Z ruf $
%*

\chapter{Evaluation und Resultate}
\label{evaluation}

Dieses Kapitel präsentiert die Resultate unserer Arbeit und beschreibt die Ansätze und Verfahren, die wir verwendeten, um die portierte Version von TOPSY v3 zu evaluieren.

\section{Methodik}
\label{evaluation:methodology}
Im Rahmen dieser Aufgabe lässt sich die für die Sicherstellung der Qualität des Resultats geleistete Arbeit in zwei Teilbereiche unterscheiden: Wie bereits im Kapitel \ref{design} angeführt, setzten wir zunächst während der Entwicklung einen iterativen Rapid Prototyping-Ansatz ein: Wir identifizierten zunächst durch schrittweises Ausführen, Register- und Speicherinspektion sowie die Ausgabe von Debug-Output mittels \texttt{printf()} den ersten Codebereich, in dem die Ausführung vom erwarteten Verhalten abwich. Dann behoben wir unter Zuhilfenahme von Dokumentation und Linux-Source Code, gelegentlich auch Trial and Error, den Fehler, und verifizierten die korrekte Ausführung des Abschnittes --- falls die Prüfung erfolgreich ausfiel, begann die nächste Iteration. \\
Da wir kein von Grund auf neues Betriebssystem, sondern lediglich eine auf eine neue Plattform der nächsten Hardwaregeneration portierte Version eines bestehenden Produkts erarbeiteten, beschränkte sich die Validierung dabei auf das Sicherstellen des korrekten Ausführung des Hardware Abstraction Layers und dessen einwandfreie Zusammenarbeit mit den Kernelmodulen. Wir verzichteten deshalb darauf, aktiv nach Fehlern im portablen Teilen des Kernels zu suchen, und konzentrierten uns primär auf die Abarbeitung des Startvorgangs und die Ausführung der in TOPSY v3 enthaltenen User Space-Programme. Dieser Ansatz vereinfachte die Aufgabe der Validierung erheblich, und liess trotz des stark reduzierten Aufwands verlässliche Aussagen über die Codequalität zu. \\
Vor diesem Hintergrund wurde nach dem Abschluss der Codierarbeiten in einem zweiten Schritt die Durchführung einer relativ einfachen qualitativen und quantitativen Evaluation vorgesehen. Dafür wurden im Emulator die Start- und Endzeiten von vier für das Funktionieren des Betriebssystems zentralen Vorgängen gemessen, und die im folgenden abgedruckte Ausgabe der \texttt{start hello}- und \texttt{start demo-}Befehle erzeugt.

\section{Resultate der Evaluation}
\label{evaluation:results}
Seit dem Abschluss dieser Semesterarbeit laufen der TOPSY~v3-Kernel und die User Space-Programme wie in der Aufgabenstellung spezifiziert gleichermassen stabil auf dem IXP2400-Emulator und Hardwareplattform. Die Initialisierung der Hardware und aller Module von TOPSY verläuft einwandfrei, und die grosse Mehrheit der User Space-Programme werden anstandslos und zuverlässig ausgeführt. \\
In der Tabelle \ref{tab:evaluation} finden sich die Resultate der quantitativen Evaluation, die in der Emulatorumgebung gemessen wurden. 

\begin{table}
\begin{center}
\begin{minipage}{\textwidth}
\begin{tabular}{| p{165pt} | c | c | c | c |}
\hline
Messgrösse & Start (hex) & Ende (hex) & Cycles & benötigte Zeit\\
\hline
Message Passing von Kernel- zu Kernel-Protection Domain & 0x7dda58 & 0x7ddf7d & 1317 & 2.195$\mu$s\\
\hline
Message Passing von User- zu User-Protection Domain & 0x5cd945b & 0x5cea4c1 & 69734 & 116.2$\mu$s\\
\hline
Laden des user.bin-Images und Starten der Shell (mit \texttt{printf}) & 0x8a4393 & 0x9176d4 & 471873 & 0.786ms\\
\hline
Laden des user.bin-Images und Starten der Shell (ohne \texttt{printf}) & 0x8144f2 & 0x86fa9c & 374186 & 0.623ms\\
\hline
\end{tabular}
\end{minipage}
\caption{Resultate der quantitativen Evaluation}
\label{tab:evaluation}
\end{center}
\end{table}

Stellvertretend für das laufende Betriebssystem wird zur qualitativen Evaluation ausserdem die Ausgabe der \texttt{start hello}- und \texttt{start demo}-Befehle in der TOPSY~v3-Shell wiedergegeben:
\begin{verbatim}Topsy Shell 3.0 (c) 1998, ETH Zurich, TIK
Type 'start licence' to print the licence terms governing your use 
of this product.

($Id: Shell.h 2911 2007-03-07 13:27:12Z rnatau $)

> start hello
COMMAND: start hello

threadBuild: stack base 0xcfdfe000 mappedBase 0x60000000, stackStart 
0xcfefdffc, mappedStart 0x600ffffc
Exception: cause 4, 0x5 0x600fffe0 0 [PC 0x0c208e5c]
vm_region_free: free region form 0x60000000 - 0x600fffff
Exception: cause 4, 0x5 0xcfefdfac 0 [PC 0x0d002de8]
Hello World

vm_region_free: free region form 0xcfdfe000 - 0xcfefdfff
> start demo
COMMAND: start demo

threadBuild: stack base 0xcfdfe000 mappedBase 0x60000000, stackStart 
0xcfefdffc, mappedStart 0x600ffffc
Exception: cause 4, 0x5 0x600fffe0 0 [PC 0x0c208e5c]
vm_region_free: free region form 0x60000000 - 0x600fffff
parent started

threadBuild: stack base 0xcfcfd000 mappedBase 0x60000000, stackStart 
0xcfdfcffc, mappedStart 0x600ffffc
Exception: cause 4, 0x5 0x600fffe0 0 [PC 0x0c208e5c]
vm_region_free: free region form 0x60000000 - 0x600fffff
Exception: cause 4, 0x5 0xcfdfcfb4 0 [PC 0x0d002f38]
parent running

child started

parent received message from child

child running

vm_region_free: free region form 0xcfcfd000 - 0xcfdfcfff
parent continuing

exit of child

vm_region_free: free region form 0xcfdfe000 - 0xcfefdfff
\end{verbatim}

\section{Beurteilung}
\label{evaluation:assessment}

Die Validierung eines Basisbetriebssystems ist eine notorisch schwierige Aufgabe. Bedingt durch den im Vergleich zu anderen Softwareprojekten typischerweise grossen Funktionsumfang, die Nebenläufigkeit der verschiedenen Prozesse und die Eigenheit, dass die weite Teile der Software direkt mit der Hardware kommunizieren, ist es grundsätzlich sehr schwierig, die Stabilität und das erwartungsgemässe Funktionieren eines Betriebssystems in allen denkbaren Situationen zu garantieren. \\
In unserem Fall kommt erschwerend hinzu, dass wir den grössten Teil der Entwicklungs- und Validierungsarbeit in der Emulatorumgebung vornahmen, und deshalb die Zuverlässigkeit der Resultate stark vom übereinstimmenden Verhalten von Hardware und Emulator abhängt.\\
Da wir allerdings aufgrund des verfolgten Entwicklungsansatzes einen grossen Teil der Validierung des Codes während der Entwicklungsarbeit erbracht haben, gehen wir trotzdem davon aus, dass unser Resultat die Ansprüche für im Rahmen von Semesterarbeiten entwickelte Software weitestgehend erfüllt. Der Umstand, dass sich bei der Inbetriebnahme der Hardware nach der Fertigstellung der Emulatorversion kaum Unterschiede im Ausführungsverhalten auftraten, entkräftet die Vorbehalte gegenüber der Entwicklung in einer solchen Umgebung wenigstens teilweise. Und während die Portierung von der IXP1200-Plattform auf den IXP2400-Emulator den Grossteil der investierten Zeit in Anspruch nahm, benötigte die Inbetriebnahme der Hardware nur einige Arbeitstage, woran die serielle Schnittstelle den grössten Anteil hatte. Diese Gründe rechtfertigen die Annahme, dass sich Aussagen über die während der Entwicklung erreichte Stabilität in der Emulatorumgebung grundsätzlich auf die Hardware übertragen lassen. \\
Für den Fall, dass TOPSY v3 den produktiven Betrieb aufnehmen soll, wäre es allerdings ratsam, die Einheit von Betriebssystem und entwickelter User Space-Software nochmals eingehend und sorgfältig auf ihre Zuverlässigkeit im Dauereinsatz und unter hoher Belastung zu überprüfen. Dieser Aspekt erhielt als Konsequenz der verfolgten Entwicklungsmethodik ein relativ geringes Gewicht.