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


\chapter{\label{coding:continuation}Ansätze zur Weiterentwicklung und Problembehebung}

In diesem Abschnitt möchten wir einen Ausblick auf zukünftige Entwicklungsmöglichkeiten geben. Durch den beschränkten Umfang einer Semesterarbeit war beispielsweise nur vorgesehen, den Core des IXP2400 einzusetzen. Die in der Summe leistungsfähigeren Packetprozessoren bleiben beim Einsatz von TOPSY auf dem IXP2400 ungenutzt. Es wäre eine sinnvolle Erweiterung, Module wie den Netzwerkstack teilweise auszulagern. Wesentlich anspruchsvoller, aber auch von höherem akademischem Wert, wäre die Entwicklung eines Frameworks, das die Ansteuerung der Packetprozessoren aus dem User Space erlaubt, oder sogar eine Just-In-Time-Kompilierung von ARM-Instruktionen in ein Programm vornimmt, dessen repetitive Abschnitte auf den Packetprozessoren ausgeführt werden.\\
Neben den Paketprozessoren bietet die IXP2400-Hardware noch eine Reihe weiterer attraktiver Features, die von TOPSY in seiner heutigen Form nicht verwendet werden: Es wäre beispielsweise relativ einfach, einen Treiber für die Hardware-Hashing Unit zu schreiben, um ohne Belastung des Cores 48-, 64- und 128-bit-SHAc-Hashes zu errechnen. Gleichermassen könnte man die drei heute unbenutzten Timer in Betrieb nehmen und den User Space-Programmen anbieten oder für das Betriebssystem einsetzen.\\
Ein besonderes Merkmal von TOPSY~v3 ist die ausgefeilte Speicherverwaltung. Deren Features wurden zwar implementiert, machen aber von der hardwareseitigen Unterstützung nicht vollen Gebrauch. So unterstützt der Prozessor neben dem TOPSY-Standard von 4kb auch Seitengrössen von 1kb und 64kb, und bei 4kb- und 64kb-Seiten auch Subpages von einem Viertel der Grösse mit separaten Zugriffsberechtigungen. Darüber hinaus ist auch das Zusammenfassen von mehreren Seiten zu sogenannten Domains möglich, deren Rechte dann mit einem einzelnen Zugriff verändert werden können. Der Einsatz einiger dieser Features im Memory Management wäre eine naheliegende, sinnvolle Erweiterung.\\
Im Kapitel \ref{topsy} gingen wir auf die Grundsätze und Zielsetzungen der Entwicklung von TOPSY ein. Die dort beschriebene Ausrichtung auf den universitären Unterricht ist sowohl ein Vor- als auch ein Nachteil: Die Maximen der Portabilität und der Verständlichkeit des Codes beschränken die Ausrichtung auf bestimmte Plattform und die Komplexität der Programmierung. In der Praxis erschweren sie, dass TOPSY auf einer spezifischen Plattform jemals seine volle Leistungsfähigkeit unter Beweis stellen kann, da diesbezügliche Optimierungen den Entwicklungsprinzipien zuwiderlaufen. Falls allerdings ein praktischer Einsatz, beispielsweise als Node~OS auf einem Embedded Device, realisiert werden soll, dürfte es gerade dank diesen Prinzipien sowohl bestehenden Entwicklern wie Neuzugängen der TOPSY-Entwicklergemeinschaft leicht fallen, die performancerelevanten Teilsysteme zu identifizieren, von den Eigenschaften der eingesetzten Hardware Gebrauch zu machen, und so die Performance des Betriebssystems deutlich zu steigern. 