% Hauptseminar Betriebssysteme. Exokernel Architektur
% Von Chris Hodges
% 18. Mai 2000
%
% Folien
%

\documentclass[%
  slidesonly,%
  %notes,%
  %notesonly,%
  a4]{seminar}

\usepackage[latin1]{inputenc}
\usepackage{epsfig}
\usepackage{german}
\usepackage{fancybox}

\def\printlandscape{\special{landscape}}    % Works with dvips.
%\twoup
\slideframe{oval}
\pagestyle{headings}

\begin{document}
\slidewidth24cm


\begin{slide} % Titelseite
\sffamily
\begin{center}
{\huge Hauptseminar Betriebssysteme}

\vspace{4ex}

{\Huge Die Exokernel Architektur}

{\large Chris Hodges\\18. Mai 2000}
\end{center}

\end{slide}

\begin{slide} % Gliederung
\sffamily
\begin{center}
{\LARGE Gliederung}
\end{center}

\vspace{4ex}

\large
\begin{enumerate}
\item Einleitung und Motivation
\item Exokernel-Konzepte
\item Ziele und Realisierung
\item Implementationen und Beispiele
\item Probleme
\item Schlußfolgerung
\end{enumerate}

\end{slide}

\begin{slide} % Motivation
\sffamily
\begin{center}
{\LARGE Motivation}
\end{center}

\vspace{4ex}

\large
\begin{itemize}
\item Traditionelle OSe langsam, unzuverlässig, unflexibel
\item Grund: Es kann keine allgemeingültige Abstraktion geben
\item Abstraktion beschränkt Innovation und Optimierungsmöglichkeiten
\item Abstraktion wichtig für Applikationsprogrammierer:
\begin{itemize}
\item Normierte Schnittstelle
\item Unkomplizierte Programmierung
\item Keine Kenntnisse der unterliegenden Hardware nötig
\end{itemize}
\item Lösung? $\Rightarrow$ Abstraktion aus dem Kern nehmen
\end{itemize}

\end{slide}

\begin{slide} % Eleminierung der Abstraktion
\sffamily
\begin{center}
{\LARGE Eleminierung der Abstraktion}
\end{center}

\vspace{4ex}

\large
\begin{itemize}
\item Keine Abstraktion durch den Kern, sondern Veräußerung der Hardware direkt
\item Kern schützt die Ressourcen, verwaltet sie nicht
\item Exokernel kennt die Semantik der Ressource nur bei der Zuteilung
\item Abstraktion auf Applikationsebene: libOS'e teilen sich die Hardware
\item Innovation möglich: Anpassung eines libOS für spezielle Bedürfnisse
\end{itemize}

\end{slide}

\begin{slide} % Design-Ziele
\sffamily
\begin{center}
{\LARGE Design-Ziele}
\end{center}

\vspace{4ex}

\large
\begin{enumerate}
\item Trennung von Schutz und Verwaltung
\item Offenlegen der Hardware
\item Explizite Allokation
\item Sichtbare Revokation
\item Schutz von Einheiten minimaler Größe
\item Verwendung physikalischer Namen
\item Kern-Informationen veröffentlichen
\end{enumerate}

\end{slide}

\begin{slide} % Trennung von Schutz und Verwaltung
\sffamily
\begin{center}
{\LARGE 1. Trennung von Schutz und Verwaltung:\\Secure Bindings}
\end{center}

\vspace{4ex}

\large
Kern beschränkt sich auf Mechanismen zum Schutz von Ressourcen bei der
Allokation.

Vorteile:
\begin{itemize}
\item Kern prüft nur bei der Anforderung die Autorisation\\
$\Rightarrow$ Applikation erhält \textit{secure binding} als Verknüpfung zur Hardware
\item Schnell: Zugriff über secure bindings, Kern muß Semantik nicht verstehen
\end{itemize}

\end{slide}

\begin{slide} % Offenlegen der Hardware
\sffamily
\begin{center}
{\LARGE 2. Offenlegen der Hardware:}
\end{center}

\vspace{4ex}

\large
Möglichst niedriger Abstraktionsgrad, Reservierung der Ressourcen auf
Hardwareebene (z.B. Speicherseiten, DMA, MMU-Mappings, Interrupts) -- keine
Virtualisierung!

Vorteile:
\begin{itemize}
\item Hardwarenahes API liefert maximale Informationen\\
$\Rightarrow$Anpassung der Applikation möglich
\item Hardware kann direkt und optimal genutzt werden
\end{itemize}

\end{slide}

\begin{slide} % Explizite Allokation
\sffamily
\begin{center}
{\LARGE 3. Explizite Allokation:}
\end{center}

\vspace{4ex}

\large
Applikation kann selbst entscheiden, welche Instanzen von Ressourcen reserviert werden.

Beispiel:

Applikation (Dateisystem) kann explizit angeben, wann welcher Block zu
reservieren ist $\Rightarrow$ gewünschtes Layout auf der Festplatte

\end{slide}

\begin{slide} % Sichtbare Revokation
\sffamily
\begin{center}
{\LARGE 4. Sichtbare Revokation:}
\end{center}

\vspace{4ex}

Traditionelles OS: Revokation transparent $\Rightarrow$ Speicherseiten
werden ausgelagert, ohne Wissen der Applikation

\large
Exokernel: Applikation erhält Aufforderungen, Ressourcen freizugeben
$\Rightarrow$ Applikation \textbf{weiß}, daß z.B. Speicher knapp ist und
\textbf{bestimmt selbst}, welche Seite sie zurückgeben will

Kommt die Applikation der Aufforderung nicht nach, wird die Ressource
gewaltsam entzogen und die Applikation darüber informiert.
\end{slide}

\begin{slide} % Schutz von Einheiten minimaler Größe
\sffamily
\begin{center}
{\LARGE 5. Schutz von Einheiten minimaler Größe:}
\end{center}

\vspace{4ex}

\large
Verwendung von Einheiten geringer Granularität: Speicherseiten, Diskblöcke,
etc.

Vorteile:
\begin{itemize}
\item nur Schutz ganzer Einheiten durch Exokernel\\
$\Rightarrow$ Kern braucht keine Hierarchie zu verwalten.
\item Overhead/Komplexität der Verwaltung gering
\end{itemize}
\end{slide}

\begin{slide} % Verwendung physikalischer Namen
\sffamily
\begin{center}
{\LARGE 6. Verwendung physikalischer Namen:}
\end{center}

\vspace{4ex}

\large
Exokernel verwendet physikalische Namen wo möglich. Diese enthalten
wertvolle (Hardware-) Informationen.

Vorteile:
\begin{itemize}
\item weniger Speicherverbrauch durch Mapping-Tabellen
\item Verwertung der Information für Optimierungen
\end{itemize}

Beispiel: \texttt{xcp} ist dadurch doppelt so schnell wie \texttt{cp}

\end{slide}

\begin{slide} % Kern-Informationen veröffentlichen
\sffamily
\begin{center}
{\LARGE 7. Kern-Informationen veröffentlichen:}
\end{center}

\vspace{4ex}

\large
Der Exokernel veröffentlicht Daten, die nur er bereitstellen kann (oder an
die Applikationen nur schwer kommen).

Beispiele:
\begin{itemize}
\item Cache-Statistik
\item Prozeßumgebung
\item Auslastung etc.
\end{itemize}
\end{slide}

\begin{slide} % Betriebssysteme als Bibliotheken
\sffamily
\begin{center}
{\LARGE Betriebssysteme als Bibliotheken\\libOS'e}
\end{center}

\vspace{4ex}

\large
\begin{itemize}
\item Wiedereinführung der Abstraktion für Applikationsprogrammierer:\\
$\Rightarrow$ virtueller Speicher, Dateisysteme, Prozesse, etc.
\item optimiertes libOS für spezielle Bedürfnisse $\Rightarrow$
Flexibilität!
\item libOS'e koexistieren harmonisch, Kern multiplext Ressourcen.
\item Entwicklung vereinfacht: Kein Rebootzyklus mehr, Anwendungen eines
anderen libOS laufen stabil
\end{itemize}
\end{slide}

\begin{slide} % In den Kern ladbarer Code
\sffamily
\begin{center}
{\LARGE In den Kern ladbarer Code\\ASHs, DPFs, UDFs}
\end{center}

\vspace{4ex}

\large
Application-specific Safe Handlers (ASHs):
\begin{itemize}
\item Vermeidung von Kontextwechseln
\item Aufwecken von Applikationen aufgrund von Ereignissen
\item Geringe Latenzzeit
\end{itemize}

Dynamic Packet Filters (DPFs):
\begin{itemize}
\item effiziente Filter, geringe Latenzzeit
\item sicheres Multiplexen von Netzwerkpaketen
\end{itemize}
\newpage
\begin{center}
{\LARGE In den Kern ladbarer Code\\ASHs, DPFs, UDFs}
\end{center}

\vspace{4ex}

Untrusted Deterministic Functions (UDFs):
\begin{itemize}
\item sicheres Verwalten von Diskblöcken
\item Kern muß nichts über das Layout wissen
\item Kern kann die Verwaltungsstrukturen mitbenutzen
\end{itemize}
\newpage
\small
\begin{verbatim}
% Initialisation: Sicherstellen, daß owns(meta) in einem gültigen
% Zustand ist, d.h. meta sollte keine Bloecke enthalten.
proc initialize(meta)
    if owns(meta) != {}
        error "Fehlerhafter Grundzustand!"
end;

% Allokation: meta soll Zugriff auf Diskblock b erhalten
proc allocate(meta,b)
    alte_menge = owns(meta) % alten Zustand aufzeichnen
    <Dateisystem macht beliebige Veraenderungen>
    neue_menge = owns(meta) % neuen Zustand aufzeichnen

    % Ueberpruefen, dass die Menge genau um b gewachsen ist
    if neue_menge != alte_menge U { b }
        error "Fehlerhafte Veraenderung!"
end;
\end{verbatim}

\end{slide}

\begin{slide} % Kann man ein Exokernel System bauen?
\sffamily
\begin{center}
{\LARGE Kann man ein Exokernel System bauen?}
\end{center}

\vspace{4ex}

\large
Antwort: Ja! Es wurden bisher drei gebaut: Aegis, Glaze und Xok.

\begin{itemize}
\item Aegis\\
Erste Entwicklung auf DEC-Stations. Optimiert auf Mikrobenchmarks.
\item Glaze\\
Exokernel für SPARC Multiprozessor-Systeme.
\item Xok\\
Fortgeschrittenste Implementation für x86.
\end{itemize}
\end{slide}

\begin{slide} % Mikrobenchmarks von Aegis / ExOS
\sffamily
\begin{center}
{\LARGE Mikrobenchmarks von Aegis / ExOS}
%\end{center}

%\vspace{4ex}

\scriptsize

%\begin{center}
  \begin{tabular}{|l|l|l|r|r|}
  \hline
  \textbf{Maschine} & MHz & \textbf{OS} & \textbf{Überlauf} & \textbf{Speicherschutzfehler} \\
  \hline
  DEC2100 & 12.5 MHz & Ultrix & 208,0 & 238,0 \\
  DEC2100 & 12.5 MHz & Aegis & 2,8 & 3,0 \\
  \hline
  DEC3100 & 16.67 MHz & Ultrix & 151,0 & 177,0 \\
  DEC3100 & 16.67 MHz &Aegis & 2,1 & 2,3 \\
  \hline
  DEC5000/125 & 25.0 MHz & Ultrix & 130,0 & 154,0 \\
  DEC5000/125 & 25.0 MHz & Aegis & 1,5 & 1,5 \\
  \hline
  \end{tabular}
  \\
  \textsc{\small Zeit um eine Ausnahmebedingung zu behandeln.}

  \begin{tabular}{|l|l|l|r|r|}
  \hline
  \textbf{Maschine} & MHz & \textbf{OS} & \textbf{pipe} & \textbf{shm} \\
  \hline
  DEC2100 & 12.5 MHz & Ultrix & 326,0 & 187,0 \\
  DEC2100 & 12.5 MHz & Aegis & 30,9 & 12,4 \\
  \hline
  DEC3100 & 16.67 MHz & Ultrix & 243,0 & 139,0 \\
  DEC3100 & 16.67 MHz &Aegis & 22,6 & 9,3 \\
  \hline
  DEC5000/125 & 25.0 MHz & Ultrix & 199,0 & 118,0 \\
  DEC5000/125 & 25.0 MHz & Aegis & 14,2 & 5,7 \\
  \hline
  \end{tabular}
  \\
  \textsc{\small Interprozeßkommunikation mit pipes und shared memory.}
\end{center}

\end{slide}

\begin{slide} % Wodurch?
\sffamily
\begin{center}
{\LARGE Gründe für die hohe Performance}
\end{center}

\vspace{4ex}

\large
\begin{itemize}
\item Im Kern nur Datenstrukturen ohne MMU-Mapping
\item IPC übergibt dem Partner nur den CPU-Kontext
\item Application-specific Safe Handlers / DPFs
\end{itemize}

\end{slide}

\begin{slide} % Globale Performance
\sffamily
\begin{center}
{\LARGE Globale Performance / Xok/ExOS}
%\end{center}

\vspace{2ex}
\mbox{\epsfxsize=0.9\textwidth \epsffile{unmodunix.eps}}

\end{center}
\end{slide}

\begin{slide} % Cheetah-Webserver
\sffamily
\begin{center}
{\LARGE Optimierte Software: Cheetah-Webserver}
%\end{center}

\vspace{2ex}
\mbox{\epsfxsize=0.9\textwidth \epsffile{cheetah.eps}}

\end{center}
\end{slide}

\begin{slide} % Cheetahs Optimierungen
\sffamily
\begin{center}
{\LARGE Optimierungen in Cheetah}
\end{center}

\vspace{4ex}
\large
\begin{itemize}
\item Eigene optimierte TCP/IP Implementierung
\item Verschmelzung von Datei- und Sendepuffer
\item Zusammenfassung kleiner TCP-Pakete
\item Dateigruppierung mit C-FFS Dateisystem
\end{itemize}
\end{slide}

\begin{slide} % Probleme
\sffamily
\begin{center}
{\LARGE Probleme:}
\end{center}

\vspace{4ex}
\large
\begin{itemize}
\item Schnittstellendesign schwierig
\item Jetzige Implementation schützt nicht alle Kernstrukturen
\item Verlust von Information für den Kern
\item Möglicherweise große Applikationen durch libOS'e
\item Kernentwicklung verläuft langsam (Stillstand?)
\item Momentan nicht wirklich verfügbar
\end{itemize}
\end{slide}

\begin{slide} % Fazit Performance
\sffamily
\begin{center}
{\LARGE Fazit:}
\end{center}

\vspace{4ex}
\large
\begin{itemize}
\item Abstraktion im Kern ist nicht notwendig
\item Hardware kann sicher veräußert werden
\item Geschwindigkeit unoptimierter Applikationen ist ähnlich oder höher
\item Performance angepaßter Applikationen ist sehr viel höher
\item Programmierer hat die Möglichkeit zur Innovation
\item Software-Entwicklung gestaltet sich einfach
\item Probleme lösbar oder nicht schwerwiegend
\end{itemize}
\end{slide}

\end{document}