%*
%* Copyright (c) 2007 by Lukas Ruf (lukas.ruf@lpr.ch)
%*
%* Create: 2007-01-30:1600
%* Modify: 2007-01-30:1611
%* Commit: $Id: related.tex 3053 2007-08-20 19:32:27Z sryffel $
%*

% Frühere Arbeiten
% Related Work
% In Beziehung stehende Arbeiten
\chapter{Verwandte Arbeiten}
\label{related}

% In diesem Kapitel werden die Arbeitsbereiche und der Umfang dieser Arbeit
% aufgezeigt. Zuerst wird die Struktur des, auf alten ia32-Prozessoren lauffähigen,
% Topsy i386 und nachher die von Topsy v3 gezeigt. Anhand der Unterschiede und
% Neuerungen von Topsy v3 wird im Kapitel \ref{problem:problem} die
% Aufgabenstellung präzisiert. 

Topsy ist ein für Unterrichtszwecke geschriebenes,
multihreading fähiges Microkernel Betriebssystem, dessen
Interprozesskommunikation auf dem Message-Passing Konzept aufbaut. Im
Rahmen diverser Semester- und Diplomarbeiten wurde Topsy stetig erweitert
und auf neue Plattformen portiert. 

In diesem Kapitel werden die für diese Arbeit relevanten Arbeiten vorgestellt.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Topsy v1}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{related:topsyv1}

Topsy v1 wurde 1996 von George Fankhauser für den MIPS R3000 entwickelt
\cite{bib:topsy}. 

 \subsection{Aufbau von Topsy v1}

Die Abbildung \ref{fig:v1vsv3} auf Seite \pageref{fig:v1vsv3} zeigt auf der linken Hälfte den
Aufbau von Topsy v1. Er besteht aus drei Schichten. 

\subsubsection{User}

Zuoberst ist der User Layer. Dort laufen die Shell und weitere,
unprivilegierte Threads des Benutzers. Die Interprozesskommunikation, also die
Kommunikation unter den Threads, läuft über Nachrichten. Der gleiche Mechanismus
wird auch für die Schnittstelle zu den Threads der Kernel Schicht verwendet.



\subsubsection{Kernel}

Das Herzstück von Topsy ist die Kernel Schicht. Der Kernel ist
 gemäss dem Microkernel-Ansatz auf unabhängige Threads aufgeteilt,
welche ihrerseits über Nachrichten kommunizieren. Im laufenden Betrieb sind in
Topsy v1 vier Kernel Threads aktiv:
\begin{description}
  \item[Memory Management Thread] (MM-Thread) verwaltet den verfügbaren
  Speicher. 
  Die anderen Threads delegieren das Allozieren und später das Freigeben von
  Speicherbereichen an diesen Thread. 
   
  \item[Thread Management Thread] (TM-Thread) verwaltet alle Threads. Er kann
  Threads erstellen, starten oder beenden. Wenn ein Thread terminiert,
  wird er von diesem Kernel Thread automatisch wieder aus dem System entfernt. 
  Threads können freiwillig die CPU abgeben, indem sie eine
  Yield Nachricht an den TM-Thread senden.
  
  \item[Input/Output Thread] (IO-Thread) verwaltet Input/Output-Ressourcen wie
  zum Beispiel die Konsole oder die Tastatur. Um ein Gerät zu öffnen, davon zu
  lesen, schreiben oder es wieder zu schliessen, muss eine entsprechender Syscall
  zum IO-Thread initiiert werden.

  \item[Idle Thread] ist immer lauffähig und wird vom Scheduler nur gewählt,
  wenn alle anderen Threads blockiert sind. Der Idle Thread hält dann die CPU an.
\end{description}

In der Kernel Schicht sind zwei weitere Module angesiedelt: Das
Topsy-Modul und der Startup-Prozess. Das Topsy Modul kann als eine Art
Kernel Library gesehen werden. Es beinhaltet das Syscall Interface und stellt
den Kernel Threads verschiedene Datentypen und die dazugehörigen Routinen zur
Verfügung.

Im Startup-Modul befindet sich die Routine \code{topsyMain()}, welche nach dem 
Booten als erste architektur-unabhängige Funktion aufgerufen wird. Dort wird 
die Konsole initialisiert und der MM- und TM-Thread gestartet.

\subsubsection{Hardware Abstraction Layer}

Der Hardware Abstraction Layer (HAL) stellt dem Kernel auf jeder Architektur eine
einheitliche Schnittstelle zur Verfügung. Zu seinen wichtigsten Funktionalitäten
gehören das Interrupt Management und Handling, sowie die Realisierung der
Interprozesskommunikation und Memory Management. 
 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Topsy i386}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{related:topsyi386} 

Die erste Portierung von Topsy wurde 1998 von Lukas Ruf durchgeführt. Während
seiner Semesterarbeit portierte er das MIPS-Topsy v1 auf PC/AT kompatible
Computer mit Prozessoren der ia32-Architektur
\cite{bib:topsyi386}. Damit zeigte er die Portierbarkeit von Topsy auf und legte
den Grundstein für die vorliegende Arbeit. Lukas Rufs Version von Topsy wird
Topsy i386 genannt.

Topsy i386 implementiert einen Boot-Prozess, welcher die Hardware
initialisiert, Topsy lädt und in den architektur-unabhängigen Code springt.
Zudem wurde der ganze HAL-Layer, also Memory-, Thread-Management, Input/Output
und Interprozesskommunikation (IPC), portiert. Des weiteren beinhaltete die Arbeit
Treiber für Videoausgabe und Tastatur.


\subsection{Schwächen von Topsy i386}

In diesem Kapitel werden einige Schwächen der ersten ia32-Portierung aufgeführt.

\subsubsection{Speicherschutz}

Topsy i386 kennt kein Paging und dementsprechend laufen alle Threads im
gleichen Adressraum. Dieser Adressraum ist grundsätzlich für alle Threads lesbar
und schreibbar. 

Um dennoch  Speicherschutz zu gewährleisten,
verwenden Kernel  und User Threads verschiedene Segmentselektoren. Mit
Segmentselektoren kann der verfügbare Speicher einer Applikation auf einen
beliebigen Bereich eingeschränkt werden. Für Threads der User Schicht wird
dieser so gewählt, dass der Code und die Daten des Kernels ausserhalb liegen.
So wird der Speicher des Kernels vor fehlerhaften und böswilligen Threads des
Users abgeschottet. Letztere sind aber weder untereinander noch vor dem Kernel
geschützt. Zudem können User Threads auf den Stack der Kernel Threads zugreifen
und diesen sogar verändern. Der Speicherschutz ist also nur minimal.


\subsubsection{Aktueller Zustand}

Topsy  i386 bootete und lief zuletzt 2001 auf einem Pentium II mit 200MHz.
Seither hat sich Topsy stetig weiter entwickelt und viele neue Features
bekommen, ohne dass die ia32-Portierung angepasst worden wäre. 

% Die wichtigsten Änderungen
% fanden mit der Version 3 statt, welche im Kapitel \ref{related:topsyv3} auf
% Seite \pageref{related:topsyv3} vorgestellt wird. 

\subsubsection{Multi Prozessor Unterstützung}

Topsy i386 läuft nur auf einem Prozessor. Um dies zu ändern, müssten die 
Kriterien der Multi-Prozessor Spezifikation \cite{bib:mpspec} von Intel erfüllt 
werden. Diese definiert ein PC/AT-kompatibles Multiprozessor-Design und bewahrt 
dabei vollständige PC/AT-Binärkompatibilität. Sie spezifiziert alle für das 
Betriebssystem relevanten Komponenten. Obwohl diese Komponenten in allen 
modernen Prozessoren vorhanden sind und auch in Singleprozessor-Systemen 
Vorteile bringen, kann Topsy i386 deren Funktionalitäten nicht nutzen.



\begin{sidewaysfigure}
  \centering
  \includegraphics[width=\textwidth]{topsy-v1-vs-v3.pdf}
  \caption{Topsy v1 vs Topsy v3}
  \label{fig:v1vsv3}
\end{sidewaysfigure}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Topsy v3}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{related:topsyv3}

Die Diplomarbeit `Topsy v3' von Claudio Jeker und Boris Lutz ``brachte Topsy einen
Schritt weiter in Richtung NodeOS, in dem sie es mit einem modernen Speicher-,
Prozess- und IO-Management ausstatteten'' \cite{bib:topsyv3}. 

% NodeOS wird im Kapitel Motivation der Einführung definiert.

Wie in der Abbildung \ref{fig:v1vsv3} ersichtlich, lässt sich Topsy v3 
in drei Schichten unterteilen: Unprivileged, Privileged und Microkernel. 

Die Unprivileged Schicht entspricht in etwa der User Schicht des alten Topsys. In
ihr werden die Applikationen des Benutzers ausgeführt. Die Kernel Threads sind in
der
Privileged Schicht angesiedelt. Der Microkernel besteht im Wesentlichen nur
noch aus einem Interrupt Handler und dem für die IPC zuständigen Nachrichten
Dispatcher. 



\subsection{Neuerungen in Topsy v3}

Drei wesentliche Neuerungen wurden eingeführt, die nachfolgend einzeln
betrachtet werden:

\subsubsection{Protection Domains}

In Topsy v3 läuft jede Anwendung in einer sogenannten Protection Domain (PD). 
Eine Protection Domain definiert für alle Threads der Anwendung einen 
gemeinsamen virtuellen Adressraum und Grenzwerte für Prioritäten und 
Zugriffsberechtigungen. So werden die Threads einer Anwendung vor 
äusseren Einwirkungen durch Threads anderer Anwendungen geschützt. Dies stellt neue 
Anforderungen an Topsy und insbesondere an das Speichermanagement, welches nun 
virtuelle Adressräume unterstützen muss.

% Wenn nun auch einzelne Kernel Threads in verschiedenen Protection Domains
% ausgeführt werden, wird das System noch sicherer und modularer. 

\subsubsection{Memory Management}

Für die Implementation verschiedener virtueller Adressräume verwendet das neue Memory
Management Paging. Dazu wurde das Memory Management von Grund auf neu
entwickelt und durch ein ausgeklügeltes, objektorientiertes System ersetzt.
Wie in Topsy v1 müssen Speicherbereiche über Nachrichten an den Memory
Manager angefordert und wieder freigegeben werden. Diese werden dann bei Bedarf
gemappt und belegen vorher noch keinen physikalischen Speicher.

Speicher kann auch zwischen verschiedenen Protection Domains geshared werden. Zum
Beispiel, wenn mehrere Threads den gleichen Programmcode teilen oder
Shared-Memory verwenden. Topsy v3 beherrscht auch Copy-on-Write, bei dem eine zu
kopierende Region erst beim ersten Schreibzugriff wirklich kopiert wird. 

\subsubsection{Interprozesskommunikation}

Da nun nicht mehr alle Threads den gleichen Adressraum haben, musste
für Topsy v3 auch die Interprozesskommunikation neu designed werden. Nachrichten
sollten möglichst effizient zwischen Protection Domains ausgetauscht werden können,
ohne dabei eine Lücke in den Speicherschutz zu reissen. 

Die gewählte Lösung basiert auf einem zweistufigen Ansatz. Kleine Nachrichten
werden von einer Protection Domain in die anderen kopiert. Für grössere
kann ein Transportbehälter (Enveloppe) angehängt werden. Ein
Loan-out-Mechanismus erlaubt es, diesen dann temporär in eine andere
Protection Domain zu mappen. So kann der aufwendige Kopiervorgang umgangen werden. 

\subsection{Zusammenfassung}

Claudio Jeker und Boris Lutz trieben den Microkernel Ansatz noch weiter und 
führten Topsy auf ein neues Level. 
% Jetzt können sogar die Kernel Threads in 
% eigenen Protection Domains betrieben werden. 
Topsy ist nun nicht mehr nur 
multithreading-, sondern auch multitasking-fähig. Die Neuerungen haben 
weitreichende Konsequenzen für alle Subsysteme. Topsy v3 wurde nur für die  
MIPS Architektur, und für dem IXP1200 von Intel implementiert. 



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%\section{TopsySMP}
%\label{related:topsysmp}
%\ldots \?

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Linux Kernel}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{related:linux}

% Ich nehme die untenstehende Aussage zurück, da ich keine Referenz habe.
%  ``Der Linux Kernel \cite{bib:linux} läuft auf mehr Plattformen und unterstützt
%    mehr Hardware als die meisten anderen Betriebssysteme.''

Der Linux Kernel \cite{bib:linux} läuft auf diversen Plattformen, 
wobei die Zielplattform und Prozessorarchitektur dieser Arbeit die älteste und 
in \cite{bib:understandinglinux} auch sehr gut dokumentiert ist. Zusammen mit 
der Verfügbarkeit des Quellcodes ist der Linux Kernel eine gute Anlaufstelle 
bei Unklarheiten in den Spezifikationen und dient dieser Arbeit als 
Referenzimplementation.

Durch sein monolithisches Design, in dem der Kernel Teil eines jeden Prozesses
ist, unterscheidet er sich fundamental vom Microkernel-OS Topsy. Dennoch konnten
einige interessante Techniken übernommen werden. 


% Konzept: Kernel Mode Stacks mit \code{\_\_get\_thread\_from\_esp();}


