%****************************************************************************
%** Copyright 2002 by Lukas Ruf, ruf@topsy.net
%** Information is provided under the terms of the
%** GNU Free Documentation License http://www.gnu.org/copyleft/fdl.html
%** Fairness: Cite the source of information, visit http://www.topsy.net
%****************************************************************************
%****************************************************************************
%** Last Modification: 2005-07-11 1600
%** 2005-07-11	Bernhard Tellenbach
%**							This is an addapted version of the Introduction.tex file
%**							Added table example (footnotes,multicolumn)
%**							Examples for different text sizes
%**							Updated eps file inclusion example for use with graphicx pkt.
%****************************************************************************

\chapter{\label{problem}Herausforderungen}

% After we have extracted the white-spots in \chapref{related}, we
% can formulate and precisely define the problem what we are going
% to solve.  It is your task to show in this chapter
% that you have understood what you are going to solve.


Das Ziel dieser Arbeit ist, die Lücke zwischen der aktuellen Version von Topsy 
und dem ia32-Port zu schliessen. Schliesslich soll Topsy v3 auf einem 
PC/AT-kompatiblen Rechner mit einer CPU ab Pentium 4 \cite{bib:ia32spec} stabil 
laufen. Beispiele dafür sind, neben dem Pentium 4 selber, der Pentium M 
\cite{bib:ia32spec} oder der der Multicore Prozessor Intel Core Duo 
\cite{bib:ia32spec}.

In diesem Kapitel wird zuerst die Aufgabenstellung konkretisiert und nachher auf
einige spezielle Herausforderungen eingegangen. 

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

\section{Aufgabenstellung}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{problem:problem}

Wie bei den meisten Portierungen fällt der grösste Teil der Arbeit am Hardware 
Abstraction Layer an. Dieser muss an die neuen Schnittstellen von Topsy v3 
angepasst werden und die neuen Features unterstützen. Da ein Design-Ziel von 
Topsy die Portierbarkeit ist und die neue Version schon auf mehreren 
Architekturen läuft, darf an den architektur-unabhängigen Teilen so wenig wie 
möglich geändert werden.




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

\section{Herausforderungen}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{problem:challenges}

Obwohl sich die Arbeit vor allem auf den HAL konzentriert, ist es nötig, die
darüber liegenden Schichten bis ins Detail zu verstehen.
Nur mit dem Wissen, zu welchem Zweck, in welchem Kontext und in welcher
Reihenfolge die zu implementierenden Funktionen aufgerufen werden, können diese
richtig portiert werden. Dies setzt ein grosses Detailverständnis der
Topsy-Mechanismen voraus. 

Diese müssen möglichst effizient auf der Ziel-Plattform umgesetzt werden. Die
Intel Architektur lässt dem Entwickler viele Freiheiten, indem sie für vieles
verschiedene Lösungsvarianten zulässt. Dies und der Umstand, dass die
Spezifikation \cite{bib:ia32spec} über die
Jahre immer wieder rückwärtskompatibel erweitert wurde, macht sie äusserst
komplex. Sie  umfasst mittlerweile über
dreieinhalbtausend Seiten, ohne die Multi Prozessor Spezifikation
\cite{bib:mpspec}.

Die Einführung von Protection Domains in Topsy v3 und die damit verbundene 
Verwendung von Paging hat weitreichende Konsequenzen für alle Subsysteme. Zum 
einen muss Paging aktiviert und die entsprechenden Datenstrukturen verwaltet 
werden. Zum anderen müssen alle Subsysteme so angepasst werden, dass alle 
benötigten Datenstrukturen zugreifbar sind, ohne unnötig viel gemeinsamen 
Speicher zu verwenden. Dies gilt besonders für die  Interprozesskommunikation.

Multi-Prozessor-Unterstützung, wie sie in der ursprünglichen Aufgabenstellung noch
formuliert wurde, konnte aus Zeitgründen nicht realisiert werden. Dieses
Ziel wurde aber nicht aus den Augen verloren. Diese Arbeit soll die Grundlage
schaffen, um später Topsy auf mehreren Prozessoren auszuführen.

Die Unterstützung des Advanced Programmable Interrupt Controllers (APIC) und 
I/O-APIC ist eine nötige Voraussetzung, die die Multi-Prozessor Spezifikation 
stellt. Deshalb war es ein Ziel dieser Arbeit, diese Bausteine zu 
initialisieren und so zu konfigurieren, dass Topsy auch auf Systemen mit 
mehreren Prozessoren funktioniert. Dies bringt Vorteile, auch für
Einprozessor-Systeme. 

Der APIC wurde mit dem Pentium Pro eingeführt, ist in allen neueren 
Prozessoren integriert und wird deshalb auch lokaler APIC genannt. Dieser 
empfängt Interrupts von internen Quellen, den Interrupt Pins und den externen 
I/O-APIC-Bausteinen und leitet sie an den Prozessor weiter. In 
Multi-Prozessor-Systemen sendet und empfängt er auch Nachrichten an und von 
anderen Prozessoren. Der I/O-APIC ist Teil des Chipsets. Er empfängt externe 
Interrupts des Systems und angeschlossenen Geräten und sendet sie an den 
lokalen APIC von einem oder mehreren Prozessoren.

Eine besonders grosse Herausforderung war die Überarbeitung des Thread 
Management. Der alte Interrupt Handler war nicht reentrant. Das heisst, es 
durfte immer nur maximal ein Thread im Interrupt Handler sein. Im Interrupt 
Handler dürfen also keine Unterbrechungen auftreten. Der nächste Interrupt oder 
die nächste Exception darf erst behandelt werden, wenn der Handler abgearbeitet 
ist. Dies führt zu unnötigen Verzögerungen bei der Bearbeitung von wichtigen 
Interrupts, was besonders bei Mehr-Prozessor-Systemen suboptimal ist.

Mit der Einführung von Virtual Memory ist eine neue Ausnahmebedingung möglich 
geworden: die Page Fault Exception. Ein Page Fault wird ausgelöst, wenn auf 
eine Page zugegriffen wird, die nicht im System vorhanden ist. Dieser muss 
sofort behandelt werden. Wenn der Zugriff fehlerhaft war, muss der Thread 
beendet, anderenfalls eine neue Page an dieser Stelle eingefügt und der Thread 
an der gleichen Stelle nochmals gestartet werden. Im alten Interrupt Handler 
traten mit aktiviertem Paging oft Page Faults auf, die nicht bearbeitet 
werden konnten. Um solche Nested Exceptions zu behandeln, muss der Interrupt 
Handler reentrant sein.

Nested Exceptions sind in Topsy v3 ein neues Konzept und wurden jetzt
mit dieser Arbeit erstmals eingeführt. Deshalb waren einige Änderungen am
architektur-unabhängigen Teil nötig. 
Für reentrante Interrupt Handler müssen alle globalen Datenstrukturen durch
Locks vor quasi-zeitgleichen Zugriffen geschützt werden. Schwieriger ist die
Speicherung des Unterbrechungszustandes, von denen es mit Nested Exceptions
beliebig viele geben kann. In den Unterbrechungszuständen müssen unter anderem
Informationen
des Schedulers gespeichert werden. Diese geben an, ob der Thread
blockiert ist, auf ein Ereignis wartet oder
lauffähig ist. Wenn nun ein Ereignis eintritt, müssen die Informationen des
richtigen Zustandes geändert und der Thread eventuell aktiviert werden.

Reentrante Interrupt Handler sind eine Notwendigkeit in Multicore Systemen. Da
es keine Möglichkeit gibt, Interrupts für alle CPUs gleichzeitig zu maskieren,
kann es immer sein, dass zwei CPUs gleichzeitig im Interrupt Handler sind. 

Diese Arbeit ist mehr als die blosse Portierung des HAL. Besonders die 
Einführung von Nested Exceptions und die Vorbereitungen für de Multicore 
Betrieb bedingen weitreichende Architekturänderungen am 
architektur-unabhängigen Teilen des Microkernels und an den Kernel Threads.

