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

\chapter{\label{coding}Implementation}
\label{coding:overview}
Dank der modularen Microkernel-Architektur von TOPSY lassen sich die für diese Arbeit wichtigen Codeabschnitte sehr genau bestimmen. Da TOPSY in einen hardwareabhängigen und einen hardwareunabhängigen Bereich unterteilt ist und wir keine Erweiterung der Funktionalität anstrebten, war für diese Aufgabe primär die hardwareabhängige, unterste Schicht, das Hardware Abstraction Layer (HAL), von Interesse. Abbildung \ref{figure:topsystructure} vermittelt einen Überblick über den Aufbau des Betriebssystems und zeigt horizontal die Hardware Abstraction-, Kernel- und User-Schicht, und innerhalb der Blöcke im Privileged-Bereich die verschiedenen Module, die TOPSY umfasst. \\
\begin{figure}[ht]
	\includegraphics[width=\textwidth]{TopsyStructure_Short.eps}
	\label{figure:topsystructure}
	\caption{Der modulare Aufbau von Topsy}
\end{figure}
Während der Kernel die eigentlichen Verwaltungsaufgaben eines Betriebssystems wie Thread- und Memory-Management übernimmt und die dafür nötigen Mechanismen (System Calls und Message Passing) \cite{patterson} bereitstellt, adaptiert das Hardware Abstraction Layer den Kernel an die jeweilige Hardware. Es stellt beispielsweise dem Thread Manager über den Interrupt Handler die Zeitbasis zur Verfügung, die das präemptive Multitasking benötigt. Bevor aber diese Module im Einzelnen vorgestellt werden, soll im Abschnitt \ref{coding:boot} auf den Startvorgang eingegangen werden, da von dessen erfolgreicher Ausführung alle weiteren Module abhängig sind.

\section{\label{coding:boot}Boot-Ablauf}
\label{coding:boot:overview}
Nach dem Einschalten der Versorgungsspannung beginnt der IXP2400 mit der Hardware-Initialisierung und dem Selbsttest. Darauf wird der Bootloader ausgeführt, erst dann beginnt die Abarbeitung des eigentlichen TOPSY-Codes. Dieser Abschnitt soll die Komponenten, die nicht Teil von TOPSY sind, in einem Überblick vorstellen, bevor im Anschluss detaillierter auf die einzelnen TOPSY-Module und ihre Funktion eingegangen wird. Da die Entwicklung sowohl auf der Hardware als auch in der Emulator-Umgebung stattfand, beschreiben die folgenden zwei Abschnitte kurz die jeweils nötigen Schritte für eine Inbetriebnahme der beiden Systeme.

\subsection{\label{coding:boot:loadbootimage}Laden des Boot-Image in den Arbeitsspeicher}
Im Flash~ROM der ENP-2611-Karte ist ab Werk ein Bündel von Hilfsprogrammen installiert. Da wir jedoch die gesamte Entwicklungsarbeit in der wesentlich geeigneteren Emulator-Umgebung vornahmen, verzichteten wir auf die On-board Diagnostic Suite und den Monitor, und verwendeten nur den Boot Manager für das Laden der Betriebssystem-Images. Unter der Annahme, dass das Host-Betriebssystem ein Linux-System ist, gliedert sich dieser Vorgang in folgende Schritte: 
\begin{itemize}
	\item Öffnen einer SFTP-Verbindung auf den Host, der die IXP2400-Karte beherbergt, um die \texttt{kernel.bin}- und \texttt{user.bin}-Images hochzuladen.
	\item Bereitstellen des zu ladenden Images im Verzeichnis \textasciitilde/tftp/
	\begin{verbatim}sftp user@ixp2k4.host.name
cd tftp
put user.bin
put kernel.bin\end{verbatim}
  \item Öffnen einer ersten SSH-Verbindung, um die Konsole anzuzeigen:
\begin{verbatim}ssh user@ixp2k4.host.name
sudo minicom -C minicom-ixp-$(hostname)-`date +%Y%m%d`.log ixp
\end{verbatim}
  \item Öffnen einer zweiten SSH-Verbindung, um die IXP2400-Karte zu resetten:
\begin{verbatim}ssh user@ixp.host.name
sudo enptool reset
\end{verbatim}
  Nach dem Erscheinen der Anzeige 
\begin{verbatim}== Executing boot script in 2.000 seconds - enter ^C to abort
\end{verbatim}
  im ersten SSH-Terminal muss die Ausführung des Bootscriptes mit Ctrl-C abgebrochen werden, damitImages mit den folgenden Befehlen manuell geladen werden können:
\begin{verbatim}load -r -b 0xc208000 -m tftp -h 192.168.4.2 /var/tftp/kernel.bin
load -r -b 0xd000000 -m tftp -h 192.168.4.2 /var/tftp/user.bin
\end{verbatim}
  Die Eingaben werden jeweils quittiert mit
\begin{verbatim}Raw file loaded 0x0c208000-0x0c22589c
Raw file loaded 0x0d000000-0x0d0090a0
\end{verbatim}
	\item Der Bootvorgang wird gestartet mit 
\begin{verbatim}RedBoot> go 0xc208000\end{verbatim}
und erzeugt folgende Ausgabe (stark gekürzt), die mit dem TOPSY v3-Prompt endet: \\
\begin{verbatim}Topsy 2.1 (c) 1996-2001, ETH Zurich [Arch:ixp2400, 
bert@bert, Mon Mar 12 15:40:47 CET 2007]Stack @ 0x0c234fbc
vm segmap:
physical mappings:
	0x00000000 (0000) - 0x10000000 (0x10000)
code mappings:
	text:		0x0c208000 - 0x0c21e508 (0x16508)
	data:		0x0c21f000 - 0x0c22355c (0x455c)
	bss :		0x0c22355c - 0x0c223e2c (0x8d0)
	bootsack:	0x0c233000 - 0x0c235000 (0x2000)
	opt. segment:	0x0d000000 - 0x0d008cd0 (0x8cd0)
[...]
vm_manager_init: anonymous pager loaded
vm_manager_init: file manager loaded
vm_manager_init: page stealer loaded
vm_manager_init: loan-out manager loaded
vm_manager_init: direct mapped manager loaded
Kernel Protection Domain: mapping regions ... 
starting tmMain...
starting virtual Memory Manager...
[...]
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 $)\end{verbatim}
\end{itemize}

\subsection{\label{coding:boot:loademuimage}Laden des Boot-Image in den Emulator}
Im Unterschied zur Situation, die sich in den Vorgängerarbeiten präsentierte, waren wir in der Lage, nicht nur auf der eigentlichen Plattform zu entwickeln, sondern verfügten mit dem IXP2400-Emulator \cite{emu} über ein Werkzeug, das zu beliebigen Zeitpunkten vollständigen Einblick in praktisch alle Register und den gesamten Speicher ermöglichte. Er diente als verlässliche, praxiserprobte Basis für unsere Entwicklungsarbeit, was wir mit selbstgeschriebenen Debug-Routinen nicht in dieser Form zur Verfügung gehabt hätten.\\
Der von uns verwendete Emulator wurde in einer Masterarbeit \cite{emu} von Hampa Hug erstellt und emuliert (nebst vielen anderen Plattformen) den IXP2400-Core und dessen Coprozessoren, das via SRAM- und SDRAM-Schnittstelle angeschlossene RAM sowie die serielle Schnittstelle. Im Unterschied zu anderen Produkten, beispielsweise dem in Abschnitt \ref{platform:ixp2400} erwähnten Intel-IXP-Emulator, ist die Emulation allerdings nicht notwendigerweise zyklentreu, und lässt damit grundsätzlich die Möglichkeit eines sich von der Hardware unterscheidenden Timingverhaltens zu. \\
Dieser Emulator wird nicht über die Kommandozeile konfiguriert, sondern bezieht von dort lediglich den Pfad zu einer Konfigurationsdatei. Neben anderen Angaben enthält diese auch die Pfade zu den zu ladenden Images. Eine für die Emulation von TOPSY v3 auf dem IXP2400 geeignete Konfigurationsdatei ist im folgenden wiedergegeben:
\begin{verbatim}# simarm.cfg

section cpu {
        model = "armv5"
        bigendian = 1
}
section rom {
        base = 0xffff0000
        size = 65536
}
section ram {
        base = 0x00200000
        size = 0x0fddf000
}
section load
{
        format = "binary"
        base   = 0x0C208000
        file   = "kernel.bin"
}
section load
{
        format = "binary"
        base   = 0x0D000000
        file   = "user.bin"
}
section timer {
        scale = 5
}
section serial {
        io  = 0xc0030000
        irq = 2
}
section console {
        serial = 0
}\end{verbatim}
Unter der Voraussetzung, dass bereits eine geeignete Konfigurationsdatei mit dem Namen \texttt{simarm.cfg} vorliegt, gliedert sich der Startvorgang in folgende Schritte:
\begin{itemize}
	\item Starten des Emulators mittels
	\begin{verbatim}simarm -c simarm.cfg
\end{verbatim}
  \item Öffnen eines separaten Terminals zur Darstellung der Ausgabe der seriellen Schnittstelle:
  \begin{verbatim}tail -f uart.out
\end{verbatim}
	\item Setzen von Breakpoints (optional), beispielsweise auf die Adresse 0xc208000:
	\begin{verbatim}bs c208000
\end{verbatim}
  \item Die Ausführung wird gestartet mit dem Befehl
  \begin{verbatim}gb
\end{verbatim}
und wird erst unterbrochen, wenn ein Breakpoint erreicht oder die Tastenkombination Ctrl-Space eingegeben wird.
\end{itemize}

\section{\label{coding:starts}Die Startroutine start.S}
Nach dem Laden des Betriebsystem-Images springen Bootloader und Emulator an die physikalische Adresse 0xc208000. An diese Speicherstelle wurde bereits das start.S-Assemblerfile geladen, das die Hardware initialisiert und die korrekten Parameter (beispielsweise die Endianness, Translation Modes und MMU-Erst-Initialisierung) in die Kontrollregister lädt. Diesen Initialisierungssschritten kommt deshalb besondere Bedeutung zu, weil sie den Prozessor an die in der Toolchain eingestellten Parameter anpassen. Wann immer diese Parameter geändert werden, müssen auch Einstellungen in der Toolchain angepasst werden, um die Konfiguration des Prozessors und die Konfiguration des Compilers wieder zur Übereinstimmung zu bringen. Die für TOPSY auf dem IXP2400 verwendeten Toolchain-Einstellungen finden sich im Anhang \ref{toolchain}.

\section{\label{coding:io}Input/Output}
\label{coding:io:overview}
Aus Architektur- und Sicherheitsgründen greifen generell weder der TOPSY-Kernel noch User Space-Programme direkt auf angeschlossene Hardwaregeräte wie die Netzwerk-Interfaces oder die serielle Schnittstelle zu. Stattdessen wird ein Gerätetreiber geladen, der die Funktionen des unterstützten Geräts in einem standardisierten Schema anbietet und die gerätespezifischen Eigenheiten des Zugriffs vor dem Aufrufer weitestgehend verbirgt. Das Input/Output-Modul (I/O) stellt dem Betriebssystem und den User Space-Programmen die benötigen Funktionen zur Verfügung, um über System Calls auf diese Gerätetreiber zu greifen zu können.

\subsection{\label{coding:io:serialio}I/O über die serielle Schnittstelle}
Das Input/Output-Subsystem von TOPSY bietet über das Syscall-Interface die Möglichkeit, auf die serielle Schnittstelle zuzugreifen, die die Ausgabe des Bootvorgangs und der Konsole sowie die Entgegennahme von Tastatureingaben übernimmt, und stellt damit die primäre Schnittstelle zur Umgebung zur Verfügung. \\
Im Rahmen dieser Arbeit beschränkten sich die Änderungen am I/O-Modul auf die Inbetriebnahme der seriellen Schnittstelle, die die RadiSys-Karte über das PCI-Interface mit dem Hostcomputer beziehungsweise den Emulator mit einem Output-File verbindet. Dieser Schritt war für das Gelingen der Arbeit von besonderer Bedeutung, da der Emulator Debugging nicht mit besonderen Einrichtungen unterstützt und wir damit auf den Debug-Output des Startvorgangs angewiesen waren, um die anstehenden Probleme zu identifizieren und komplexere Datenstrukturen ausgeben zu können, um Änderungen zu validieren. Die Anpassung des seriellen Schnittstellentreibers war überraschend aufwendig, da trotz des vergleichbaren Aufbaus der Schnittstelle das Layout des Memory Mapped~I/O komplett anders ausgelegt worden war, und damit grössere Anpassungen des Treibers erforderlich wurden. Da sich die Kommunikation via Interrupts nicht stabil implementieren liess, wurde ausserdem im Interesse von Zuverlässigkeit und Termintreue eine Polling-Lösung umgesetzt.

\section{\label{coding:mmu}Memory Management}
\label{coding:mmu:overview}
Dem Memory Management kommt in TOPSY~v3 besondere Bedeutung zu, weil es im Unterschied zu den gängigsten Betriebssystemen die Zugriffsberechtigungen auf einen Speicherbereich nicht nur in zwei oder vier Kategorien einteilt, sondern jedem Speicherbereich eine separate Protection Domain zuweist, die eine feinkörnige Zuteilung und Aberkennung von Zugriffsprivilegien auf andere Protection Domains ermöglicht. Die Verwaltung dieser Protection Domains ist vergleichsweise kompliziert, vereinfacht aber auch die Arbeit der Kernel- und User Space-Programmierer und macht die Speicherverwaltung von TOPSY zu einem sehr fortschrittlichen, den etablierten Lösungen überlegenen System. Insbesondere lässt es die Partitionierung des User Space in verschiedene Protection Domains zu, um die laufenden User Space-Programme von unerwünschten Zugriffen und Manipulationsversuchen seitens anderen unprivilegierten Codes zu schützen. Diese Funktionalität wird vom Memory-Subsystem bereitgestellt, während die Anpassung an die spezifische Hardware im PMap-Modul des HAL vorgenommen wird. \\

\subsection{\label{coding:mmu:mmusingmmu}Memory Management mittels der MMU}
Der IXP2400 verfügt über leistungsfähige Speicherverwaltungseinrichtungen, die über den Coprozessor 15, den System Control Coprocessor, des ARM Cores angesprochen werden. Die Speicherverwaltung unterstützt einen mehrstufigen Translation Lookaside Buffer (TLB) \cite{patterson} mit Unterstützung für Pages unterschiedlicher Grössen, Kontrolle über das Caching-Verhalten und das Zusammenfassen von mehreren Pages zu Domains mit übereinstimmenden Zugriffsberechtigungen zwecks einfacherer und effizienterer Verwaltung.\\
Auf dem IXP2400 initialisiert TOPSY die MMU in zwei Schritten: In den ersten ausgeführten Instruktionen wird in start.S die MMU vor-initialisiert, die Endianness korrekt gesetzt, die TLBs zurückgesetzt und der virtuelle Speicher direkt und ohne Zugriffsbeschränkungen auf den physikalischen Speicher gemappt. Erst in einem zweiten Schritt wird die MMU zu einem späteren Zeitpunkt vollständig initialisiert, die Translation Tables aufgesetzt und der Speicher in Protection Domains mit korrekten Zugriffsrechten unterteilt.\\
Der Intel IXP2400 unterstützt neben dem SDRAM auch das schnellere SRAM. Um die Einsetzbarkeit von TOPSY in Unterrichtsumgebungen nicht zu gefährend, verzichteten wir jedoch bewusst darauf, performancesteigernde Massnahmen zu treffen und beispielsweise die Translation Tables im SRAM abzulegen, statt der TOPSY-Standardseitengrösse von 4kb auch die hardwareseitig unterstützten 1kb-Pages einzusetzen oder den Versuch zu wagen, das Protection Domain-Modell von TOPSY mit dem Domain-Modell des IXP2400 zusammenzuführen, um von der Hardwarebeschleunigung profitieren zu können. Mehr zu diesen und anderen Erweiterungsmöglichkeiten findet sich im Abschnitt \ref{coding:continuation}.

\section{\label{coding:interrupt}Interrupt Handling und Interprozesskommunikation}
\label{coding:interrupt:overview}
Der Interrupt Handler ist zuständig für die Verarbeitung aller Interrupts, die im TOPSY-System auftreten können. Interrupts sind asynchrone oder synchrone Signale, die von Hardwarebausteinen oder Softwareinstruktionen ausgelöst werden und den Eintritt eines bestimmten Ereignisses anzeigen \cite{patterson}. Hardware-Interrupts werden üblicherweise von Hardwaretimern, Elementen des Prozessors und Schnittstellen zu Peripheriegeräten erzeugt, während Softwareinterrupts durch den Code selbst ausgelöst werden; entweder mit dedizierten Instuktionen, durch den Gebrauch von ungültigen oder unzulässigen Instruktionen oder durch den Zugriff auf geschützte Speicherbereiche. Beim Auftreten eines Interrupts speichert der Interrupt Handler den Kontext der unterbrochenen Anwendung, interpretiert die Nachricht und leitet gegebenenfalls eine Message an das zuständige Subsystem weiter, stellt den Kontext der unterbrochenen Anwendung wieder her und gibt die Kontrolle an das unterbrochene Programm zurück. In einigen Fällen wird ausserdem durch das Ausschalten übriger Interrupts verhindert, dass die Abarbeitung des Interrupts nochmals unterbrochen werden kann.\\
Das Interrupt Handling ist ein zentrales Element in allen gängigen Betriebssystemen, da vom korrekten Verhalten beim Auftreten von Interrupts viele andere Module abhängen: Gerätetreibern zeigt das Auftreten eines Interrupts an, dass neue Daten gesendet oder empfangen werden können, und das Memory Management ist darauf angewiesen, beim Zugriff auf nicht im TLB gecachte Seiten die Umsetzung von virtuellen in physikalische Adressen vornehmen zu können. Auch Syscalls lösen mittels einer spezifischen Instruktion einen Software-Interrupt aus, um die Kontrolle an den Kernel zu übergeben. \\
Aus architektonischen Gründen sind Interrupt Handler und die Interprozesskommunikation miteinander eng verzahnt und werden deshalb sinnvollerweise gemeinsam behandelt. Der von Interprozesskommunikationssystem bereitgestellte Syscall-Mechanismus ermöglicht den User Space-Programmen begrenzten Zugriff auf Teile des privilegierten Code in den Kernel-Modulen, beispielsweise die Funktionalität bestimmter Gerätetreiber. Ein direkter Aufruf hätte eine Zugriffsverletzung und die sofortige Terminierung des fehlbaren Threads zur Folge, da den User Space-Programmen generell keinerlei Zugriffsrechte auf die Kernel-Speicherbereiche gewährt wird. Anstelle eines direkten Aufrufs legt das User Space-Programm deshalb zuerst die jeweiligen Parameter im Speicher ab, um darauf durch das Auslösen eines Software-Interrupts die Kontrolle an das Betriebssystem abzugeben. Dieses interpretiert die übergebenen Parameter, überprüft die Berechtigung des Aufrufers, und führt den entsprechenden Aufruf aus. Üblicherweise wird daraufhin die Kontrolle in den User Space bzw. an den aufrufenden Thread zurückgegeben.

\subsection{\label{coding:interrupt:topsyinthandling}Interrupt Handling und IPC in TOPSY}
Als direkte Folge der leistungsfähigen Speicherverwaltungsarchitektur verwendet TOPSY ein relativ komplexes Interrupt Handling. Im Unterschied zu den herkömmlichen Betriebssystemen, die üblicherweise bloss privilegierten und unprivilegierten Code unterscheiden, lässt das Protection Domain-Modell den Fall zu, dass bei der Abarbeitung eines Interrupts weitere Interrupts ausgelöst werden, beispielsweise durch den Zugriff auf eine fremde Protection Domain innerhalb des Kernels. Dabei ist es von eminenter Wichtigkeit, dass diese Interruptkaskade nicht zu einer Endlosschleife wird, weil ein nachfolgender Interrupt wieder und wieder durch einen vorhergehenden unterbrochen wird und das System in einen sogenannten \emph{Live Lock} gerät. Die Voraussetzungen für das korrekte Funktionieren des Interrupt Handlers mit Protection Domains wurden bereits mit der Architektur von TOPSY~v3 geschaffen, unsere Aufgabe bestand in diesem Zusammenhang darin, den Coprozessor 15 korrekt anzusprechen und die verschiedenen Speicherbereiche mit den nötigen Rechten zu versehen. \\
Der Umstand, dass das Betriebssystem nicht monolithisch ist, sondern beim Transfer von Daten zwischen den verschiedenen Kernel-Modulen die Grenzen von Protection Domains überschritten werden können, stellt ausserdem zusätzliche Anforderungen an die Interprozesskommunikation (Inter-Process Communication, IPC). Die aus Effizienzgründen gebräuchliche Methode, anstelle grosser Datenmengen innerhalb des Kernels nur die Anfangsadresse der Datenstruktur zu übergeben, wird dadurch obsolet. Stattdessen implementiert der Message Handler zusammen mit dem IPC-Handler im HAL einen Mechanismus, der es zulässt, Daten in dafür vorgesehene Speicherbereiche zu schreiben, und dann statt einer physikalischen Adresse die entsprechende Seite zusammen mit den Zugriffsrechten vom Sender zum Empfänger des Seiteninhalts zu transferieren. 

\section{\label{coding:threads}Thread Management und Scheduling}
\label{coding:threads:overview}
Als präemtives Multitasking-Betriebssystem verfügt auch TOPSY über ein Thread Management. Der Thread Manager ist dabei zuständig für die Erfassung der Prozessorbelastung durch die einzelnen Prozesse und Threads, die Verwaltung der Tabellen aller zu einem Zeitpunkt existierenden Threads und die Zuteilung von Prozessorzeit, wobei nicht nur Priorität und der gegenwärtige Status des jeweiligen Threads berücksichtigt werden, sondern auch die Priorität der Protection Domain, der der Thread angehört. Für die Generierung einer verlässlichen Zeitbasis verwendet der Thread Manager dafür den Scheduler im HAL. Ausserdem ist der Thread Manager in Zusammenarbeit mit dem Memory Management für die Terminierung von Threads und Prozessen verantwortlich, die in unzulässiger Weise auf den Speicher zuzugreifen versuchen. 

\subsection{\label{coding:threads:multitasking}Präemptives Multitasking mittels der OS Timer}
Damit TOPSY als Betriebssystem mit präemptives Multitasking bezeichnet werden kann, muss es in der Lage sein, auch Prozessen die Kontrolle zu entziehen, die sich unkooperativ verhalten und dem Betriebssystem nicht freiwillig die Kontrolle übertragen. Um dieses Verhalten zu erreichen, wird der Thread Manager durch periodische Interrupts seitens des Schedulers aufgerufen und überprüft so regelmässig, ob der laufende Prozess fortgesetzt werden darf, oder die Kontrolle an einen anderen, höher priorisierten Prozess abgegeben werden muss. \\
Durch den Umstand, dass sich der Thread Manager weitgehend auf andere Kernel-Module abstützt, und die eingesetzten Verfahren zur Tabellenverwaltung und Priorisierung nicht von hardwarespezifischen Eigenheiten Gebrauch machen, waren im Bereich des Thread Managements nur kleine Anpassungen nötig. Das Sicherstellen des einwandfreien Funktionierens des Interrupt Handlers und des Memory Managements sowie die Implementation der Ansteuerung der Hardware Timer im Scheduling-Modul des HAL machten den Grossteil dieser Teilaufgabe aus.

\section{\label{cleanup}Code Cleanup}
\label{cleanup:overview}
In seiner heutigen Form ist TOPSY das Resultat harter Arbeit von über einem Dutzend Entwicklern aus dem universitären Umfeld. Ein wesentlicher Teil des investierten Aufwands wurde im Rahmen von Master- und Semesterarbeiten über eine Zeitspanne von mehreren Jahren erbracht, und obwohl die Codequalität über weite Strecken durchaus annehmbar ist, weisen doch viele, besonders die hardwarenahen, Module Artefakte dieses Entwicklungsmodus' auf. \\
Wir sind allerdings nicht die ersten, die nach einem einheitlicheren Quellcode rufen. Auf der Projektwebsite\footnote{http://www.topsy.net} findet sich eine Konvention, die von der Formatierung von Codeblöcken bis zur Benennung von Variablen unterschiedlichen Typs verschiedene Standards setzt.\\
Deshalb war es unser Ziel, als Grundlage für Folgearbeiten und als nützliche Übung für das Berufsleben die ``Taktik der verbrannten Erde'' nicht weiterzuführen, sondern unseren Code in Übereinstimmung mit den Prinzipien von TOPSY zu schreiben und die vorliegenden Dateien mit maschinellen Mitteln an den verbindlichen Standard anzupassen.

\subsection{\label{cleanup:approach}Verwendete Programme und Verfahren}
Da sich das ursprüngliche Vorhaben, den vorliegenden Code mittels bestehender Scripts in einem Stream Editor zu parsen und entsprechend den Konventionen im Anhang \ref{ccconventions} neu zu formatieren, wegen fehlender entsprechender Scripts nicht realisieren liess, und die Schaffung eines solchen Toolkits den zeitlichen Rahmen dieser Semesterarbeit gesprengt hätte, wurde diese Teilaufgabe mittels unterschiedlicher, jeweils für einen Teilaspekt geeigneter Programme erfüllt. Dabei fiel die Wahl für die Reformatierung des Codes auf die Entwicklungsumgebung von Microsoft, das Microsoft Visual Studio 2005, weil dieses Produkt ab Werk den geforderten Formatierungsstandard unterstützt. Für das effiziente Refactoring von Makros und die Überprüfung der Initialisierung von Variablen bot sich die Entwicklungsumgebung eclipse an, die mächtige, auf regulären Ausdrücken basierende Suchwerkzeuge anbietet und als Freie Software lizenziert wird. Damit war es mit vergleichsweise kleinem Aufwand möglich, diesen Aspekt der Codequalität nachhaltig zu steigern, ohne die Kompilierbarkeit des Quellcodes zu gefährden.\\
Ausserdem wurde in die Ausgabe des Startvorgangs ein Verweis auf die GNU General Public Licence \cite{gnugpl}, der dieser Quellcode untersteht, eingefügt, und die Sammlung der User-Programme wurde um den Befehl \texttt{start licence} ergänzt, der diese Lizenz im Terminal ausgibt.