Embed Size (px)
Citation preview
Universität Karlsruhe (TH)
Institut für Algorithmen undKognitive Systeme
Dynamische Rekonfiguration inTHINK
Dynamic Reconfiguration in THINK: design and implementation.
Diplomarbeit von
Juraj POLAKOVIC
Verantwortlicher Gutacher: Prof. Dr. Jacques Calmet
30. Juni 2004
Diese Arbeit wurde von mir selbständig angefertigt. Alle verwendeten Literaturstellensind im Literaturverzeichnis aufgeführt. Eine Verwendung anderer Hilfsmittel erfolgtenicht. Ich versichere dies ausdrücklich mit der nachsteheneden Unterschrift.
Karlsruhe, den 30.6.2004
Zussamenfassung
1.1 Einführung und Motivation
Mit den neuesten Entwicklungen im Bereich der mobilen und ubiquitären Compu-tersysteme entsteht auch die Notwendigkeit eines Rekonfigurationsmechanismus, derunter Beibehaltung der Dienste das System an eine neue Umgebung anpasst.
Es gibt zahlreiche Gründe ein System zu rekonfigurieren, Fehlerkorrektur oder Op-timierung der angebotenen Dienste sind nur zwei Beispiele davon.
Diese Diplomarbeit beschreibt einen möglichen Mechanismus der dynamischenRekonfiguration für das Komponenten-System THINK. Eine Übersicht des aktuellenStandes der Forschung in diesem Feld befindet sich in Kapitel 2, "ReconfigurableOperating Systems".
1.1.1 Dynamische Rekonfiguration
Zunächst führen wir die folgende Definition ein: Dynamische Rekonfiguration isteine Änderung der Systemkonfiguration ohne Dienstunterbrechung. Diese Änderungenkönnen Auswirkungen auf die existierende Funktionalität des Systems haben, indemsie diese ersetzen oder um eine neue Funktionalität erweitern.
In der Literatur findet man verwandte Konzepte, wie Extensibilität oder Adapta-bilität. Ein extensibles System kann um weitere Funktionalitäten erweitert werden.Adaptabilität ist die Fähigkeit eines Systems sich an eine neue Umgebung (Hardware)anzupassen. Wir betrachten beide Konzepte als Teil der dynamischen Rekonfiguration.
Eine andere Betrachtungsweie der dynamischen Rekonfiguration folgt aus der Be-obachtung, zu welchem Zeitpunkt des Lebenszyklusses des Betriebssystems die Rekon-figuration stattfindet, was mit den Etappen des Bauprozesses des Betriebssytems über-einstimmt. Das laufende Betriebssystem kann zum Beispiel schon im Quellcode verän-dert werden. Wir definieren die dynamische Rekonfiguration als Änderung der Spei-cherabbildung eines laufenden Systems. Alle anderen Arten der Rekonfiguration wer-den als statische Rekonfiguration aufgefasst, d.h. als Änderungen vor der Systemaus-führung.
Die Einführung eines Rekonfigurationsmechanismus hat bedeutende Auswirkun-gen auf andere Eigenschaften und Mechanismen des Betriebssystems. Manche Ent-wurfsaspekte betreffen nur den Rekonfigurationsmechanismus, während andere dasgesamte Betriebssytem beeinflussen.
3
Im Folgenden ein kurzer Überblick über die Entwurfsaspekte eines dynamischenRekonfigurationsmechanismus:
• Mechanismen und Strategien Was, wer, wann und wie darf man rekonfigurieren?Eine detaillierte Ausführung findet man in der Übersicht in Kapitel 2, "Recon-figurable Operating Systems".
• Zustandsürbertragung Eine Rekonfiguration des laufenden Betriebssystems kannzu einem Austausch von Einheiten führen. Diese Einheiten können gewisse Zus-tandsinformationen beinhalten. Es ist also notwendig diese Informationen in dieneue Einheit zu übertragen. Zum Beispiel kann ein Scheduler als eine Einheit be-trachtet werden, bei der die Prozesslisten die Zustandsinformationen darstellen.Rekonfiguriert man den Scheduler, um ein konsistentes Verhalten zu erzielen, istes also notwendig, diese Informationen von dem alten Scheduler in den neuen zuübertragen. Hier gibt es mehrere mögliche Mechanismen und Strategien: ZumBeispiel kann die Übertragung eine Transformation der Datenformate erfordern,oder man muss die neuen Daten initialisieren.
Um eine konsistente Rekonfiguration zu erreichen, muss die Aktivität in demgegebenen Systemteil beendet oder blockiert sein. Wir nennen diesen Zustand"stable state" (stabiler Zustand).
• Beschreibung des Rekonfigurationsprozesses. Neben einem flexiblen Mechanis-mus braucht man auch ein Mittel, diese Rekonfiguration zu beschreiben. Soeine Beschreibung ist gleichzeitig auch ein erster Schritt zur Formalisierungdes Rekonfigurationsprozesses und dessen formalen Beweis, um gewisse Eigen-schaften der Rekonfiguration oder des Systems zu gewährleisten. Solche For-malismen existieren bereits als sogenannte Prozesskalküle (π-calculus, ML oderM-Calculus).
Wie bereits erwähnt, hat ein Rekonfigurationsmechanismuseinen bedeutenden Ein-fluss auf andere Charakteristiken und Entwurfsaspekte des gesamten Betriebssystems.Im Folgenden seien einige davon aufgeführt:
• Performanz Einer der Gründe für die Systemrekonfiguration ist die Systemopti-mierung. Doch der Rekonfigurationsmechanismus selbst kann wiederum Grundfür einen gewissen Overhead sein, wodurch die Performanz des Systems mit demMechanismus gegenüber dem einfachen System ohne Rekonfiguration abnimmt.Es gibt zwei Arten von Overhead: einen konstanten Overhead (der Mechanis-mus kann zum Beispiel indirekte Prozeduraufrufe benutzen, wobei man bei je-dem Aufruf eines Dienstes den Preis einer Indirektion zahlt). Der Rekonfigura-tionsprozess selbst kann einige Zeit in Anspruch nehmen und eine Verspätung inder Dienstausführung verursachen.
Der Rekonfigurationsmechanismus steht also im Widerspruch zu der idealen Per-formanz des Betriebssystems. Es muss daher ein Kompromiss zwischen deridealen Performanz und der Rekonfigurationsfähigkeit gefunden werden. Typi-scherweise wäre ein schneller Rekonfigurationsmechanismus (in der Rekonfigu-rationsphase) sehr ineffizient bezüglich der normalen Laufzeit und umgekehrt.
4
• Integrität Integrität ist eine globale Eigenschaft des Betriebssystems. Alle Ein-heiten des Systems müssen korrekt sein, sonst kann das System inkorrekte Ergeb-nisse ausgeben oder sogar abstürzen. Wir betrachten hier ’offene’ System, d.h.Betriebssysteme, die Code von Dritten akzeptieren. Ein Betriebssystem, mit dy-namischer Rekonfiguration kann mit Funktionalitäten, d.h. mit fremdem Codeerweitert worden sein, der die Integrität des Systems verletzen könnte (zumBeispiel könnte die neue Einheit das Sperrprotokoll nicht beachten). Der Ent-werfer kann durch den Entwurf angemessener Mechanismen und Strategien dieIntegrität des System garantieren wollen.
Außerdem kann, wie bereits gesehen, eine Rekonfiguration eine Zustandsüber-tragung erforden. Auch hier kann der Systementwerfer die Integrität der betrof-fenen Information garantieren wollen.
• Programmierungsmodell Ein weiterer Aspekt bei dem Entwurf eines Betriebs-systems ist die Art und Weise, wie die Anwendungen dafür gebaut werden kön-nen. Anwendungen für traditionelle Betriebssysteme werden als Prozesse (oderSammlungen von Threads) betrachtet, die die Dienste des Systems über Sys-temaufrufe in Anspruch nehmen. Zum Beispiel können in komponentenbasiertenSystemen Anwendungen als eine Menge von verbundenen Komponenten gese-hen werden, die die Dienste über spezielle Bindungen an Systemkomponen-ten beanspruchen. Derartige Systeme benötigen den Einsatz von spezialisiertenHilfswerkzeugen, um Anwendungen einfacher zu entwickeln.
Der Entwurf eines rekonfigurierbaren Systems führt also zu einem Kompromisszwischen den gewünschten Eigenschaften des Betriebssystems und denen des Rekon-figurationsmechanismus selbst, je nach dem, was für ein System der Entwerfer geradebauen will.
1.1.2 Kontext
Dieses Dokument präsentiert eine Erweiterung des komponentenbasierten Rah-menwerks THINK, entwickelt von dem Objectweb Konsortium 1.
Im Allgemeinen kapselt eine Komponente Daten und bietet Funktionalitäten an,die über eine Schnittstelle verfügbar sind. Eine Komponente kann Abhängigkeitenspezifizieren (zum Beispiel als Schnittstellen-Abhängigkeiten) und auch einige nicht-funktionelle Ansprüche stellen. In vielen Komponenten-Modellen können Kompo-nenten aus anderen Komponenten gebaut werden, und diese können wiederum zwis-chen Komponenten geteilt werden. Je nach Modell variiert auch die Granularität derKomponenten. Zum Beispiel kann ein Netzwerkstapel einerseits als eine einzelneKomponente betrachtet werden, während andererseits auch jedes einzelne Protokoll,das den Stapel ausmacht, aus einer separaten Komponente gebaut sein kann. ß Ummiteinander kommunizieren zu können, sind die Komponenten mit Hilfe einer Infras-truktur miteinander verbunden, die jedes Komponenten-Modell angemessen definiert.Ein ORB zum Beispiel definiert einen Backbone über den Komponenten durch Fern-Prozeduraufrufe kommunizieren können. Ein Komponentensystem auf einer Maschinekönnte eine direkte Kommunikation (also Prozeduraufrufe) erlauben.
1http://think.objectweb.org
5
Das Konzept von Komponenten in der Softwaretechnik ist eine logische Erweiterungder Objekte und der objektorientierten Programmierung. Komponenten geben zu-sätzlich explizit an, welche Schnittstellen sie benötigen, und das Komponentensystemliefert eine Infrastruktur zum Binden von unabhängigen Komponenten.
1.2 THINK
THINK 2 ist ein Komponentenrahmenwerk zum Entwickeln von flexiblen kompo-nentenbasierten Betriebssystemen. Derartige Systeme reichen von verteilten Systemenzu eingebetteten Systemen mit einer beschränkten Ausführungsumgebung.
THINK liefert eine minimale Abstraktion von der darunterliegenden Hardware.Diese Abstraktionen werden dem Systemprogrammierer als Schnittstellen angeboten,die in Komponenten implementiert werden. Das Modell schreibt keine Granularitätvor, zum Beispiel kann sowohl eine Unterbrechungsroutine als Komponente imple-mentiert werden, als auch ein gesamter Video-Treiber. THINK definiert ein einheitlichesund flexibles Bindungs-Modell, mit dessen Hilfe man jede Art von Betriebssystemen"à la carte" zusammenbauen kann. Das THINK Rahmenwerk ist offen - jeder kannneue Schnittstellen definieren und neue Komponenten implementieren.
1.2.1 Fractal Component Model
THINK implementiert das Fractal Komponenten-Modell, entwickelt von dem Ob-jectweb Konsortium 3. Im Folgenden wird eine kurze Einführung in das Fractal Modellgegeben.
Das Fractal Komponenten-Modell wurde als ein "extensibles System von Konzepten"entwickelt, repräsentiert durch Schnitstellen (APIs), die je von einer Komponente im-plementiert werden. Fractal Komponenten kommunizieren durch Verbindungen miteinan-der. Eine Komponente ist eine Software-Einheit, die Daten kapseln und Dienste anbie-ten kann. Diese werden durch die Komponenten-Schnittstelle (funktionelle Schnittstelle)angeboten. Die verlangten Schnittstellen sind in der Komponenten-Spezifikationangegeben.Außer den funktionellen Schnittstellen kann eine Komponente auch Kontroll-Schnittstellenanbieten, die verschiedenen Ebenen der Introspektion (Selbstbeobachtung) dienen, zumBeispiel der Bindungsverwaltung. Eine Schnittstelle ist eine Menge von Operationen,die eine Komponente ausführen kann. Diese werden in Fractal mit einer IDL (InterfaceDefinition Language) beschrieben.
Intern gesehen besteht eine Komponente aus zwei Teilen, dem Controller und demInhalt. Kontroll-Schnittstellen werden in dem Controller implementiert. Außerdem übtder Controller Kontrolle über die Komponente aus, d.h. er kann Dienste weiterleitenoder blockieren usw. Jedoch ist dieses Verhalten nicht weiter spezifiziert und bleibtdaher offen. Komponenten können in andere Komponenten eingebettet sein, sowievon mehreren geteilt werden (sharing).
2THINK steht für ’THink Is Not a Kernel’.3http://fractal.objectweb.org
6
1.2.2 THINK Framework
Das THINK Rahmenwerk ist eine Implementierung des Fractal Komponenten-Modells zum Entwickeln von Betriebssystemen. Kortex ist eine Bibliothek von Kernel-Komponenten, die mehrere Modelle für Speicherverwaltung oder Prozessverwaltunganbietet. Mehrere Bindungs-Prototypen werden ebenfalls implementiert. Das Rah-menwerk erzwingt die Wiederverwendung (reuse) von Komponenten. Es gibt maschi-nenunabhängige Komponenten, die auf maschinenabhängigen Teilen aufbauen.
Das THINK Rahmenwerk beinhaltet die Kortex Schnittstellen-Berschreibungen inIDL, deren Implementierung in C, eine Generierungskette, die das Entwickeln einesTHINK Betriebssystems unterstüzt, und eine ADL, Architecture Description Language.Eine ADL dient der Beschreibung von Komponenten, d.h. welche Schnittstellen dieseimplementieren, welche benötigt werden usw. Mit Hilfe einer ADL wird auch dieSystem-Konfiguration beschrieben. Das Rahmenwerk generiert einen ’glue code’ (Kle-becode), die Infrastruktur, mit welcher die Komponenten zu einem laufenden Sys-tem assembliert werden. Doch eine ADL-Beschreibung ist nur eine statische Sichtdes Systems, der Prozess der dynamischen Rekonfiguration kann in dieser Form nichtbeschrieben werden.
1.3 Dynamische Rekonfiguration in THINK
1.3.1 Entwurfsprinzipien
Mehrere Ziele wurden bei dem Entwurf eines Mechanismus der dynamischen Rekon-figuration für das THINK Rahmenwerk verfolgt:
? der Mechanismus sollte flexibel sein, um alle Modelle der Rekonfiguration un-terstützen zu können (siehe dazu die Klassifikation in Kapitel 2, "ReconfigurableOperating Systems"),
? der Mechanismus sollte eine feinkörnige Rekonfiguration erlauben,? der Rekonfigurationsmechanismus sollte optional sein, d.h. Komponenten, die
ihn nicht benötigen, sollten davon nicht beinflusst werden,? der Mechanismus sollte einen minimalen Einfluss auf den funktionellen Teil
einer Komponente haben,? der Laufzeit-Overhead sollte minimal sein.
Ein solcher Mechanismus kann als ein spezialisierter Controller implementiert sein.Als primitive Operationen der Rekonfigurationen werden das Ersetzen von Kompo-nenten, Löschen oder Anschließen implementiert. Der Controller kann dann auch dieZustandsübertragung implementieren und kontrollieren. Nur rekonfigurierbare Kom-ponenten brauchen einen rekonfigurationsfähigen Controller, andere werden nicht be-einflusst.
Eine Rekonfiguration auf der Ebene der Komponenten erlaubt eine feinkörnigeSystem-Rekonfiguration, nämlich auf der Schnittstellen Ebene.
Um den Rekonfigurationsmechanismus zu vervollständigen, haben wir eine for-male Beschreibung der System-Konfiguration eingeführt, mit deren Hilfe man in der
7
Lage ist, die Einheiten des Systems (Komponenten, Bindungen, usw.) zu manipu-lieren (ähnlich der ADL). Eine derartige Beschreibung der System-Konfiguration istdie Grundlage der Beschreibung und der nachfolgenden Verifikation der dynamischenRekonfiguration. Dies erfolgt mit einem Regelsystem, das zuvor noch definiert werdenmuss.
1.3.2 Implementierung
Der hier vorgeschlagene Mechanismus besteht aus drei verschiedenen Teilen, dieunabhängig voneinander entworfen werden können: 1) die Zustandsübetragung zwis-chen Komponenten, 2) die Garantie des "stabilen Zustands" und 3) der Mechanismus,der diese zwei Teile koordiniert, die Komponenten lädt oder auslagert und die Bindun-gen herstellt. Die Entwurfsentscheidungen verbergen sich hinter den vorgeschlagenenKontroll-Schnittstellen.
Zustandsübertragung
Wir definieren zwei mögliche Strategien für die Zustandsübertragung, die beideunterschiedliche Vor- und Nachteile haben. Beide koexistieren und deswegen kann derMechanismus der Situation angepasst gewählt werden.
Als erste Möglichkeit kann die Einheit, die den Rekonfigurationsprozess startet, dieformale Beschreibung nutzen. Es wird vorausgesetzt, dass die Attributbeschreibung inder formalen Beschreibung formuliert wird. In diesem Fall kann man die Zustands-übertragung zwischen den Komponenten als "Regel-Mapping" zwischen Attributen indem formalen Regelsystem ausdrücken.
Alternativ dazu kann man die Zustandsübertragung der neuen Komponente über-lassen. Diese Methode ist zwar flexibler, aber die korrekte Übernahme des alten Zu-stands ist dem Komponenten-Programmierer überlassen. Dazu braucht er die Kenntnisder Struktur des Zustands seines Vorgängers. Hier ist es möglich eine "Transformations-Komponente" zu nutzen, die nur dazu dient, den alten Zustand zu transformieren undin der neuen Komponente zu integrieren.
In beiden Fällen müssen Kontroll-Schnittstellen definiert werden, die das Manipu-lieren von Attributen oder des "raw"-Zustands erlauben. Der Zugriff auf diese Schnitt-stellen kann gesichert werden, sodass nur erlaubte Einheiten den Zustand manipulierenkönnen. Im ersten Fall handelt es sich hierbei um eine Kontroll-Schnittstelle für denAttribut-Zugriff, sogennante "getters" und "setters" für jedes Attribut. Hier sieht mandeutlich den Nachteil dieser Methode - es werden interne Daten offengelegt.
Bei der zweiten Strategie definiert man eine Kontroll-Schnittstelle, die zwei Metho-den anbietet, nämlich getState() und setState(), mit denen man den "raw"-Zustand manipuliert. Es ist dem Programmierer überlassen die Struktur dieses Zu-stands zu interpretieren.
Stable state - Vorschlag I
Damit der Systemzustand korrekt ist, muss das System, bevor eine Komponenteausgelagert werden kann, sicherstellen, dass diese nicht mehr benutzt wird (stable state,
8
siehe Einführung).Um solche System-Eingeschaften zu gewährleisten, führen wir statische Proxies in
den Komponenten-Controller ein. Diese bieten der Außenwelt Schnittstellen, die zuden originalen Schnittstellen identisch sind. Die Aufrufe werden durchgeleitet, wobeiaber eine einfache Verwaltung der Aufrufe ausgeübt (reference counting) werden kann,sodass man in jedem Moment entscheiden kann, ob Aufrufe gerade ausgeführt werden.Weitere Verwaltungs-Funktionalitäten können ebenfalls in den Proxies integriert wer-den.
Eine solche Methode wirkt sich jedoch nachteilig auf die Performanz des Systemsaus - bei der Ausführung erhält man statt einem Aufruf zwei Aufrufe. Diese Nachteilekönnen mit dem nachfolgenden Vorschlag behoben werden.
Stable state - Vorschlag II
Um die Nachteile der "naiven" Version der Proxies aufzuheben, können wir dyna-mische Proxies verwenden. Diese Lösung ist komplexer und benötigt kompliziertereMechanismen, nämlich einen Thread-Generation-Swap-Mechanismus. Dieses Prinzipstammt aus dem K42 Projekt (siehe Kapitel 2, "Reconfigurable Operating Systems").
Im Prinzip wird der stabile Zustand auch hier mittels Proxies garantiert, diese wer-den jedoch erst zu Beginn der Rekonfiguration geladen. Das System muss zwei Eigen-schaften gewährleisten, damit die Überprüfung der eventuell aktiven Aufrufe erfolg-reich wird: 1) die Lebensdauer der System-Threads ist beschränkt, 2) System-Threadssind nicht-blockierend. Somit muss man nicht alle je existierenden Threads in demSystem aufzählen, sondern nur einen Generation-Swap abwarten, der garantiert, dasszum aktuellen Zeitpunkt alle Threads von dieser Generation beendet sind. Daher kannman von nun an die Aufrufe aufzählen und mit Sicherheit feststellen, wann in dergegebenen Komponente keine Aktivität mehr stattfindet.
Rekonfigurationsmechanismus
Der dritte hier vorgeschlagene Mechanismus soll die Zustandsübertragung und dasErreichen des stabilen Zustands koordinieren, sowie die Bindungen wiederherstellen.Dieser Mechanismus wird dem System-Programmierer als Schnittstelle angeboten,nämlich entweder als Schnittstellen eines speziellen Rekonfigurationsmotors, oder alsKontroll-Schnittstellen der rekonfigurierbaren Komponenten.
Beispielszenario
Als Beispielszenario möchten wir einen Router rekonfigurieren. Der Netzwerkprotokoll-Stapel (stack-Komponente) soll dabei um das SCT-Protokoll erweitert und die IP-Komponente ersetzt werden. Hier folgt nun eine vereinfachte Ausführung der Rekon-figuration für diesen Fall:
1. Rekonfigurationsanfrage für stack und IP,
2. Stable State für IP und stack; wenn erreicht, Unterbrechung der Dienste (blockie-rend),
9
3. Laden der neuen Komponenten: SCTP und IP,
4. Zustandsübertragung von IP,
5. Auslagern der alten IP-Komponente,
6. Herstellen der Bindungen im stack,
7. Wiederaufnahme der Dienste.
1.4 Fazit
Trotz des Versprechens der dynamischen Rekonfiguration in eingebetteten Syste-men sind diese Mechanismen bei Weitem noch nicht ausgereift. So wurden beispiel-sweise unserer Kenntnis nach bisher noch keine dieser Mechanismen in industriellenBetriebssystemen eingesetzt.
1.4.1 Offene Probleme
Im Kontext der Komponenten-Systeme gibt es mehrere Probleme, auf die wir indieser Arbeit nicht näher eingegangen sind:
? Die Beschreibung der System-Konfiguration muss noch definiert werden.
? Die Korrektheitsprüfung der Rekonfiguration bleibt ebenfalls offen.
? Die Zustandsübertragung wurde nicht implementiert und birgt noch offene Fra-gen.
? Es wäre interessant, den zweiten Vorschlag zum Erreichen des stabilen Zustandszu implementieren. Dazu muss jedoch überprüft werden, ob das THINK Rah-menwerk die beiden oben genannten Voraussetzungen erfüllt.
? Das oben kurz erwähnte Regelsystem muss definiert werden.
? Der Mechanismus muss noch optimiert werden.
1.4.2 Perspektiven
Wir sind der Meinung, dass neue Arten der Strukturierung eines Betriebssystemseinen bedeutenden Einfluss auf die Rekonfiguration haben werden. Zum Beispielglauben wir, dass es möglich ist, auf der Grundlage des "synchronen" Paradigmas flex-ible Betriebssysteme (synchronous programming) bauen zu können. Ein synchronesProgramm kann als ein Automat betrachtet werden, der auf externe "Stimuli" (Anre-gungen) reagiert. Nach einer derartigen Reaktion ist das System stets in einem stabilenZustand, und die Rekonfiguration kann stattfinden.
In dieser Arbeit haben wir unabhängige Systeme betrachtet. Es wäre interessant,eine Infrastruktur zu entwickeln, die den Rekonfigurationsprozess unterstützt und Teile
10
davon, wie zum Beispiel die Verifikation der Korrektheit der neuen Konfiguration,übernimmt. Eine derartige Strategie fände ihre Anwendung beispielsweise in der Mo-biltelekommunikation.
Die Optimierung des Mechanismus und der damit verbundenen Strukturen ist eben-falls noch ein Thema der Forschung, da der hier vorgeschlagene Mechanismus zahlrei-che Performanz-Nachteile mit sich bringt. Doch Optimierung bedeutet wahrschein-lich zugleich auch einen irreversiblen Informationsverlust, sodass die Rekonfigurationnach der Optimierung nicht mehr möglich ist. Es wäre demnach wünschenswert, eineOptimierungs-Methode zu finden, die reversibel ist.
11
Contents
1 Introduction 141.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.2 Dynamic reconfiguration . . . . . . . . . . . . . . . . . . . . . . . . 141.3 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2 Reconfigurable Operating Systems 192.1 Reconfiguration models . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.1 Reasons for reconfiguration . . . . . . . . . . . . . . . . . . 202.1.2 Type of reconfiguration . . . . . . . . . . . . . . . . . . . . . 212.1.3 Initiator of reconfiguration . . . . . . . . . . . . . . . . . . . 222.1.4 Reconfiguration Management . . . . . . . . . . . . . . . . . 232.1.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2 Reconfigurable Operating Systems . . . . . . . . . . . . . . . . . . . 232.2.1 Microkernel Approach . . . . . . . . . . . . . . . . . . . . . 232.2.2 SPIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.2.3 Exokernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.2.4 Vino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.2.5 Apertos and other reflective OS . . . . . . . . . . . . . . . . 302.2.6 MMLite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.2.7 K42 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3 THINK 353.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.2 Fractal Component Model . . . . . . . . . . . . . . . . . . . . . . . 353.3 THINK Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.1 Architecture Description Language . . . . . . . . . . . . . . 383.3.2 Generation Chain, Tools . . . . . . . . . . . . . . . . . . . . 393.3.3 A simple HelloWorld kernel . . . . . . . . . . . . . . . . . . 39
4 Dynamic Reconfiguration in THINK 414.1 Design Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1.1 Dynamic reconfiguration description . . . . . . . . . . . . . . 434.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
12
4.2.1 State transfer . . . . . . . . . . . . . . . . . . . . . . . . . . 464.2.2 Reconfiguration Mechanism . . . . . . . . . . . . . . . . . . 474.2.3 An example scenario . . . . . . . . . . . . . . . . . . . . . . 514.2.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5 Conclusion 545.1 Opened Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
A Synchronous programming, reactive systems 60
B HelloWorld in Think 63B.1 ADL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63B.2 Components and their implementation . . . . . . . . . . . . . . . . . 64
C Simple syntax of the system description 65C.1 System description . . . . . . . . . . . . . . . . . . . . . . . . . . . 65C.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66C.3 Reconfiguration rules . . . . . . . . . . . . . . . . . . . . . . . . . . 66
13
Chapter 1
Introduction
1.1 Motivation
With the recent advances in the area of mobile and ubiquitous computing andtelecommunication systems where high availability may be an issue, we assist moreand more to a need for a general mechanism to reconfigure the system in order to adaptit, while preserving service of the running system.
There are many reasons, why one may want to reconfigure a system. The examplesof reconfiguration include bug correction or optimization (we replace a well-definedsystem entity with a new implementation), adaptation to new hardware, adaptation tonew environment requirements (for example adding support for a new communicationprotocol) or providing applications with specific interfaces (realizing an application-specific operating system).
As an example scenario, consider a router in a telecommunication system. At thetime of its design only support for existing protocols was included in the router. How-ever, over time, a new protocol was conceived making the older one deprecated. Nowconsider that the operating system was designed with a dynamic reconfiguration mech-anism (though the system is flexible). Additionally suppose, that the system is built outof well-defined entities (we call these building blocks subsequently). To modify theprotocol stack without service interruption, one would suspend the processing of thebuilding block implementing the old protocol, while replacing it with the new one andthen resume all pending activity.
1.2 Dynamic reconfiguration
This leads us to the following: dynamic reconfiguration is the process of changingthe system configuration without service interruption. These changes include modify-ing existing functionality, as well as adding and removing functionality. In the literaturewe can find some related terms to dynamic reconfiguration, mainly adaptability and ex-tensibility. The latter refers to the capacity of the system to add new functionality andwe consider it to be an extension of the dynamic reconfiguration. Adaptability refers to
14
the ability of the system to adapt to a new hardware environment. In the context of thiswork, we consider that this case is included in our notion of dynamic reconfiguration.
Another way to approach the dynamic reconfiguration is to consider "levels" wherethe modification takes place. These levels correspond to build steps of an executableimage of an operating system: Runnable code may be altered by modifying code at
one of these steps. However, we define dynamic reconfiguration as the last case -modifying in memory a running representation of the operating system. As opposed tostatic reconfiguration - modifying the system prior to its execution.
Introducing dynamic reconfiguration in an operating system has an important im-pact at two different levels. Some design issues concern only the reconfiguration mech-anism itself, whereas some issues are global to the whole operating system. We addressthese issues in detail in the following.
• Mechanism and Policies Mechanisms and policies themselves. This involvesdefining entities that may be reconfigured, in what context the reconfigurationmay take place (policies), the degree of automation... A more detailed discussionwill be found in the following chapter.
• State transfer Possibly, the reconfiguration of the system may involve the re-placement of an entity (what we called building block), that also contains somestate information. For example the system’s scheduler contains the process queues.If needed, the reconfiguration mechanism must transfer (and maybe transform)the state between the reconfigured entities. Indeed, the reconfiguration policymay allow state loss in some cases, whereas it may require state conservation inall other cases. The new entity may contain more information (extended state),needing a policy to initialize this part of the new data.
In order to reconfigure a part of the running system, we must ensure, that allactivity in this part has terminated. We call this state a "stable state". Withoutsuch stability, the state of the system part could change while being reconfigured,breaking the system integrity.
• Description of the reconfiguration process. The mechanism as such may be flex-ible, but some means are also needed to express what is going to be reconfiguredand how the reconfiguration is going to take place (what entities are involved andhow they are replaced, how the state is going to be transferred..).
15
Such a description is a step towards a formalization of the reconfiguration pro-cess and its formal proof in order to guarantee some global properties of thesystem after the reconfiguration. Such formalisms already exist in the form ofprocess calculi (π-calculus, ML or the M-Calculus).
As stated in Denys et al. [12] introducing dynamic reconfiguration into an operatingsystem leads to confrontation with the following strong related characteristics of theoperating system.
• Performance One of the reasons why a reconfiguration mechanism may be in-troduced in an operating system is to enable performance optimization. How-ever the mechanism itself may induce some overhead, resulting in worse perfor-mance than a similar system without the reconfiguration mechanism. There aretwo types of overhead a dynamic reconfiguration mechanism may induce. Firsta constant run-time overhead may be induced (For example a reconfigurationmechanism may be implemented with the use of indirections, resolved at eachprocedure call. A system without the mechanism would use direct procedurecall). As a second type of overhead, the reconfiguration itself may also cause animportant overhead (it may include some analyze, verification, loading ...).
A dynamic reconfiguration mechanism is running against the ideal performanceof the operating system. So there is a trade-off between performance and the re-configuration capability. Typically a mechanism, that optimizes to minimize thetime spent in the reconfiguration phase is not going to be efficient at run-time,because of a constant overhead that it causes. And vice versa the reconfigura-tion phase is going to be complex and thus slow, if having an efficient run-timesystem, for example with direct calls between building blocks.
• Integrity Integrity is a global property of an operating system, all parts mustfunction correctly, otherwise the whole system will misbehave. This addressesthe "openness" of the operating system (A system is open, if it can accept third-party code). Dynamic reconfiguration as introduced may include extending therunning operating kernel with some new (possibly third-party) code, thus thesystem may get corrupted, for example if the new entity does not respect thelocking protocol (see Bershad on "Issues in the Design of an Extensible Opera-ting System", [6]).
Moreover the dynamic reconfiguration may involve state transfer between oldsystem entities to new ones. The system designer may want to ensure and thusguarantee the integrity of the information contained in these entities.
There are two approaches to integrity: the system does not enforce any integritypolicy or there exists a mechanism that guarantees the system’s integrity. In thefirst approach, the system may not provide any mechanism to enforce its correct-ness and may hope, that the reconfiguration is not going to corrupt the system.This can be extended with a trust relationship, for example as it is done in Linuxat two levels: Only the (trusted) administrator may load new "loadable kernelmodules", and the administrator trusts the module providers for providing cor-rect modules. The second approach is more complex and may include following
16
mechanisms: verification and protection. Verification ensures the correctness ofthe new code before its introduction in the system (for example compilation andcertification techniques), whereas protection attempts to ensure that the code be-haves correctly after installation and bounds the damage if it does not (again, seeBershad et al., [6]). There exist a variety of protection techniques and Bershadin his work identifies different areas, where some protection mechanism shouldbe applied (similar to Ch.Small et al. in [37]). For example in order to protectthe kernel from misbehaved extensions accessing forbidden memory, or callingforbidden kernel functions, a system could use a "safe" language approach (en-suring some run-time properties, typically verifying properties at compilationtime and by inserting some run-time check code in the compiled code) or simplyisolating the extension in a separate address space..
• Programming model Another important characteristic of an operating system isthe way how applications are built on top of it. This has impact on how applica-tions should be developed and it may require special tools to build them. Tradi-tionally applications are built as processes (or a collection of threads), requiringoperating system services through system calls. Whereas in a component-basedoperating system applications may be built as a set of interconnected componentsaccessing system services through special bindings to system components.
Building a reconfigurable operating system results in a trade-off between strongrelated issues in the design of an operating system, for example designing a systemwith the focus on integrity may result in a relatively inefficient (performance) system,in the same way as bloating the system interface that makes the programming modelcomfortable for the application designer.
1.3 Context
This document presents the work completed in the scope of the THINK component-based operating system developed at France Télécom R&D 1 and INRIA 2 within theObjectWeb consortium 3. ObjectWeb promotes the development of open-source mid-dleware for cutting-edge applications. THINK is licensed under the GNU GeneralPublic and is freely available.
Generally a component encapsulates some data and provides some well-definedfunctionalities through well-defined interfaces. A component may specify required de-pendencies (in terms of interfaces for example) and some non-functional requirements.In many component models, components may be built out of other components andthese can also be shared between several components. Also the granularity of a com-ponent may vary depending on the model. For example we may consider the completenetwork stack as a component, as well as a single packet that will traverse it.
In order to enable components to communicate, a component-system provides aninfrastructure. Components are connected together by means of this infrastructure,
1http://www.rd.francetelecom.com/2http://www.inrialpes.fr3http://www.objectweb.org
17
that defines the mode of communication. For example an ORB defines a backbone forcomponents that communicate through remote calls, or a component-system on onemachine may allow components to directly call procedures from other components.
The concept of components in software technology is a logical enhancement toobjects. In addition to objects, component-systems provide means to express depen-dencies, as well as an infrastructure to connect components together to build a system.
We mean to build operating systems for embedded devices with strong run-timeconstraints, as memory size limitation for example. The component technology enablesus to build specialized operating systems by assembling only necessary components.Also various implementations of an interface may be provided, optimizing the memoryfootprint for example.
Furthermore, apart from structuring the operating system around components, wecould port additional techniques from the component-based software methodology, asthe separation of concerns and the Aspect-Oriented Programming. Applying thesetechniques to build operating systems may be of concern in future operating systemresearch projects, yet they must be well-understood. This work is closely related toflexible component-based middleware (see Jonathan, OpenORB, OLAN, 2k), howeverwe limit the scope only to operating systems, aiming towards light-weighted embeddedarchitectures.
This master thesis is organized in five chapters, starting with the state of the artof dynamic reconfiguration in operating systems and some properties of dynamic re-configuration. Briefly we shall then describe the THINK framework. Our propositionof designing and implementing dynamic reconfiguration in THINK is then presented,followed by an evaluation of the work and a conclusion.
18
Chapter 2
Reconfigurable OperatingSystems
Early operating systems were built as large monolithic blocks, difficult to main-tain and inflexible. Microkernels first introduced some modularity and flexibility inoperating systems. Since then there have been efforts in research to improve theseaspects in operating systems and with the advent of embedded systems, new require-ments emerged. Recent research projects in embedded systems focus on several issuesconcerning design of ’new generation’ operating systems (Stankovic et al. [39] andDenys et al. [12]).
Structuration
Structuration of an operating system was a first concern, designing a high flexiblesystem supporting easily new types of hardware and allowing a variety of deploymentscenarios. The structuration consists in separating the kernel in well-defined buildingblocks. From the software engineering view, the operating is written as modular soft-ware. One step further, the operating system is composed of separate entities - buildingblocks, that can be identified at run-time. Pursuing this idea, we could then build spe-cial purpose systems, only by assembling the necessary building blocks. For examplewe could build a router, only by providing the network stack.
Extensibility
Extensibility of the kernel is the first step for improving application performancewith application specific-code integrated into the kernel. The protection of the kernel iscrucial in these systems, because the kernel will possibly accept some third-party code.A lot of research went on such application-specific operating systems, generally ex-tending a kernel with mechanisms, that guarantee the integrity of the operating system.For example, some mechanisms combine static verification of the code to insert (thisinvolves a kernel-level compiler) and a run-time protection (checking every operationexecuted by the extension).
19
Performance
Microkernels are not outdated, some research projects, like the L4 family of micro-kernels, still believe in the flexibility and performance of microkernel-based systems.Yet, recognizing the bad performance of these, their focus is on improving the perfor-mance of microkernels for fulfilling emerging requirements of embedded applications,in particular flexibility.
Resource management
The primary goal of an operating system is to provide applications with convenientaccess to the underlying resources. This main line is followed by some projects, likeExokernel, providing only resource abstractions to applications, leaving the freedomfor applications to implement policies and management over these.
Heterogeneity
With the growth and diversification of mobile devices, the mastering of heterogene-ity becomes an important issue when designing a new operating system for embeddeddevices. The evolution of these requires the operating system to be easily and rapidlyported to a new hardware platform.
Dynamic reconfiguration
This is the first step toward "autonomous systems", providing the system with amechanism to adapt itself to the changing environment (see the Initiator of reconfigu-ration in 2.1.3). Currently few systems address the issue of dynamic reconfiguration.
The following chapter is structured as follows. First a taxonomy of reconfigurationmodels is introduced, then some research operating systems that have some reconfigu-ration support are analyzed and a summary classification is drawn at the end.
2.1 Reconfiguration models
In this section we try to separate design issues and properties of a dynamic re-configuration model (as partially described in the survey by Denys et al. [12] and inthe thesis of A.Senart, [35]). Several obvious properties can be defined, like what toreconfigure, why or where the decision takes place?
2.1.1 Reasons for reconfiguration
A reconfiguration may be performed for several reasons, which can be classified infour categories: corrective, adaptive, extending and perfective.
20
Corrective
A misbehaving component may be replaced with a corrected component of thesame type (ie providing the same functionality).
Adaptive
Adapt the operating system to a new environment, for example plugging a newdevice into the system or the appearance of a new virus may require an update of theoperating system.
Extending
Extend the operating system with some new functionality, for example with a newnetwork protocol.
Perfective
The intent of perfective reconfiguration is to provide a better suited implementation,even if the current implementation runs correctly, for example we might want to replacean entity implementing a file system with an optimized version supporting caching.
2.1.2 Type of reconfiguration
This answers the question of what can be reconfigured. In a component-basedoperating system we identify the following types of reconfiguration (described byCunin et al. in [29] and [28]): implementation, interface, architecture and geography.
Implementation
We may want to replace an implementation of some component with another (mo-tivated by corrective, perfective or adaptive reasons). Interfaces exported by the com-ponent remain the same.
Interface
This type of adaptation modifies the list and type of interfaces provided by a com-ponent by adding or removing an interface from the component’s interface list.
Architecture
This type of reconfiguration affects the structure of the system. New componentscan be added, existing components may be removed or the interconnection betweencomponents may be modified.
21
Geography
If we consider a distributed operating system, built of components residing on dif-ferent sites, this reconfiguration corresponds to the migration of components to anothersite, for example for better load balancing. However this doesn’t affect the architectureof the application.
2.1.3 Initiator of reconfiguration
We distinguish three types of initiator of the dynamic reconfiguration process, froma manual intervention to a complete autonomous reconfiguration. This answers thequestion of Who? initiates the system reconfiguration.
Human
The system administrator or even the system user may tune the system at run-time.Modifying some kernel parameters through the proc filesystem in Linux or loading akernel module are some typical examples.
Application
In order to achieve better performance, an application may want to customize thesystem’s interface to provide itself with more efficient access to the underlying hard-ware. This category of operating systems are called Application-Specific OperatingSystems and were generally implemented as extensible microkernels (Bershad et al.[4]). Denys et al. in [12] identifies two types of application-initiated reconfiguration:
• user-level adaptation - in microkernel operating systems, all services are imple-mented as servers running at user-level. An application can provide user-levelservers that better fulfill its needs.
• kernel-level adaptation - a kernel, that permits reconfiguration at the privilegedlevel needs to enforce integrity, as discussed in the previous chapter (1.2). Gen-erally this is achieved by combining verification and protection..
Automatic
The adaptation is initiated by the system itself, without any need of interventionfrom applications or administrator. For example, a system could observe its perfor-mance and decide to replace and reconfigure a subsystem to improve performance.Here we encounter problems faced in the domain of control systems (stability, hier-archical command, observability...). However in embedded operating systems theseissues have not been resolved, for example for special purpose systems, do we want toimprove overall performance or specific subsystem performance? Paging is the onlyexample of such an ’automatic’ control in an operating system - in order to avoid trash-ing, the system observes the overall swapping behavior and adapts the number of pagesin a working set of processes. In any case, this would be the ultimate goal of reconfig-urable operating systems (Denys et al. [12]).
22
2.1.4 Reconfiguration Management
Dynamic reconfiguration as described previously, is a process local to the device(possibly a constrained embedded system), where the operating system instance runs.The running system initiates a reconfiguration, eventually downloading new implemen-tation of some entities, verifying these and proceeding.
In a more general view, we can consider the operating system as being integratedin a global architecture. From the point of view of reconfiguration, the system canbe either standalone (independent) or dependent on this network infrastructure (donot confuse with the infrastructure in a component-based system). For example thenetwork infrastructure may hold a code repository for the reconfiguration, which isa simple dependency. We could pursue this idea to its extreme and move some ofthe parts of the reconfiguration mechanism into the network infrastructure, giving upindependence of the instance of the operating system.
The dynamic reconfiguration mechanism can be split in parts, some being imple-mented in-the-box and others in the Network Infrastructure. For example the expensiveverification of compatibility of a new component can take place in the network infras-tructure. Furthermore, this approach requires a definition of a communication protocolbetween the device to be reconfigured and the network infrastructure.
At the time of this writing, none of the research projects investigated this aspect.For example we could imagine a strongly typed component-based operating systemrunning on a mobile phone. The access provider’s network infrastructure is holding theconfiguration graph and when reconfiguration is needed, it verifies the conformity ofthe new component and submits the last to the mobile-phone with precise instructionsto reconfigure the system correctly. However without the network infrastructure, themobile-phone can’t do any reconfiguration and is strongly tied to the provider.
2.1.5 Summary
The following table summarizes the design issues of a dynamic reconfigurationmodel.
2.2 Reconfigurable Operating Systems
In the following, we will attempt to give a brief overview of some approachesto build ’new generation’ operating systems, that support some degree of dynamicreconfiguration. This overview is then summarized at the end. The focus is on researchprojects, because there are about 100 industrial real-time embedded systems, mostlyin-house systems (Stankovic et al. [39]).
2.2.1 Microkernel Approach
“Ideally, the µ-kernel implements only address spaces, interprocess communica-tion (IPC), and basic scheduling.” J. Liedtke (Toward Real µ-kernels , [33])
23
Reasons CorrectiveExtendingAdaptivePerfective
Type ImplementationInterfaceArchitectureGeography
Initiator HumanApplication (user/kernel -level)Automatic
Reconfiguration Management StandaloneNetwork Infrastructure
Table 2.1: Summary of reconfiguration design issues
The word ’kernel’ denotes the part of the operating system that is mandatory toall other software. The idea behind the microkernel (µ-kernel ) is to minimize thispart, implementing operating system services as user-level servers outside the kernelthat communicate through the microkernel with IPC. In monolithic kernels the com-plete operating system was built as a single “object” allowing no run-time separation(less comprehensive, resource management policies fixed, not adaptable...) (Liedtke in[33]).
The microkernel approach is the oldest concept discussed in this survey (term in-troduced by B.Hansen in [21] in 1970 and in Hydra [41] in 1974). This concept intro-duced many advantages (software technological) compared to ’traditional’ monolithickernels:
? Coexistence of different APIs or even OS personalities implemented by the serverson top of the µ-kernel
? Flexibility and extensibility - only selected servers need to be modified and re-placed
? Common facilities provided by the µ-kernel : such as IPC and multi-threading
? Protection at server boundary, also for device drivers, that can be implementedin separate address space each.
? Small kernel - should be easily maintained and less error-prone
? OS structuring - provide a modular structure and simple (more comprehensiveand easily manipulated) abstractions
? Construction of customized systems adapted to diverse contexts
The microkernel idea, with its primary purpose as a new operating structure toachieve modular, portable system extensions, was accepted for different reasons: 1)
24
general flexibility (compared to monolithic kernels), 2) microkernels offered a tech-nique allowing the coexistence of several OS personalities (This was interesting atthat time - preserve the Unix compatibility while developing post-Unix systems) and3) hardware protection - in addition to user applications, system servers and devicedrivers were running at the user-level in different address-spaces. See figure 2.1.
Although, the first generation microkernels could not make good account of theseadvantages. The opinions differ, why the first generation failed. Liedtke (in his pub-lications: [33], [32], [31], [18]) argues that first generation microkernels failed ex-clusively on performance ground. According to Liedtke, bad performance is mainlydue to the size of the first microkernels, inducing a large memory footprint and a highcache miss-rate on address-space switches. As stated by Liedtke in [32], these arenot inherited from the concept but mostly from overloading the kernel and from im-proper implementation. Also, the bad performance is due to improper implementationof the communication primitives, the most critical mechanism (1 Remote ProcedureCall takes 2 IPCs, so 2 user-kernel mode switches). For Liedtke, bad performance isthe only cause of inflexibility - to minimize the communication overhead, the systemdesigner tends to merge servers together in few large “multi-servers”, increasing thegrain of reconfigurable entities, leading to inflexibility. On the other hand, MMLiteresearchers in [22] argue, that inflexibility is inherent to the design, that leads to ineffi-ciencies. These can be reduced by good implementation but never eliminated.
To gain acceptance, Liedtke ([31]) proposes to aggressively optimize the IPC mech-anism and provide only the right abstractions, because the chosen set of abstractionsintegrated in the kernel profoundly affects both performance and flexibility. The secondgeneration µ-kernels follow a radical new design, see L4 for example. The conceptsaround L4 microkernels were pushed to the extreme, see the L4Ka web-site ([30]) fora review of a multitude of techniques to achieve better performance (for example lazyprocess switching).
With regard to dynamic reconfiguration, microkernels provide only coarse-grainedcustomization at the level of services, i.e. running server. Depending on the design, mi-crokernels do not support any explicit reconfiguration mechanism. To reconfigure dur-ing execution a microkernel based-system, for example by replacing a running server,we would have to use some ad-hoc mechanisms, such as killing the server (whichstops it and discards it from memory), starting the new one and re-establish bindingsto those servers, that were using the replaced server. However, from the microkernelpoint of view, except from blocking the calls to the non-existing server, no mechanismis provided to transfer state between reconfigured servers, nor is guarantee of integrityprovided.
Microkernels followed up a number of research projects all exploring some direc-tions from the outline given by the microkernels to achieve better performance andfine-grained adaptability and extensibility. The L4 family of µ-kernels promotes a pureµ-kernel approach to improve performance and therefore the flexibility. The Exokernelgoes one step further in providing only abstraction of the underlying hardware with aminimum of mechanism on top. SPIN, among others, explores the way of extendingthe (micro-)kernel with application specific code.
25
syst
em s
erve
r
clie
nt a
pplic
atio
n
clie
nt a
pplic
atio
n
syst
em s
erve
r
clie
nt a
pplic
atio
n
...
microkernel
hardware
user−level
kernel−level
Figure 2.1: Microkernel: general concept
2.2.2 SPIN
SPIN, as described by Bershad et al. in [4], is an extensible microkernel devel-oped at the University of Washington in Seattle, WA. It stems from research that hasaddressed performance problems of extensible operating systems. For more referenceson SPIN see the included bibliography (Bershad et al. [7], [6], [5]).
The goals of an extensible system recognized by the research group around SPINare: 1) extensibility 2) "safety" - correctness of extensions achieved through compile-time verification and runtime protection 3) performance (faster and with less complex-ity) - achieved as well with the compiler technology.
In SPIN, adaptability is achieved through extension of the underlying microkernelin the form of a kernel-level code specified by the application, removing the expen-sive address space crossing when a user-level server or an application wants to reactto a system event or requests complex interaction between the user-level part and thekernel-level part. The figure 2.2 shows a structure of a SPIN system. A set of low-levelresource controllers provide a few fundamental abstractions (threads, basic memoryabstraction ...) which do not contain any management policy. The policies are imple-mented as extensions or a default policy is applied. All other services are implementedas extensions.
As shown in this figure (2.2), an application can be partitioned into an applica-tion component, application-specific kernel component and possibly a user-level servercomponent. These application-specific components, extensions, are called spindles(SPIN Dynamically Loaded Extension). This mechanism enables a service to be parti-tioned across the user-kernel boundary.
To ensure kernel integrity, SPIN relies on safe language features, as found in Modula-3 which provides safety and encapsulation mechanisms (interfaces) aswell as runtimeand compile-time support. A spindle (kernel extension) is written in Modula-3 anddefined as a module exporting an interface and importing other interfaces from somemodules1. The running system exports a set of interfaces, that can be accessed fromthe spindle. Spindles are verified at compile time if they invoke allowed operations on
1in SPIN the module corresponds to what we called the building block or the entity to reconfigure
26
the imported interfaces. Before installation the runtime extension checker ensures thatthe given spindle doesn’t compromise the system integrity. Applications can still bewritten in any language.
The extension model is built on top of an event-based communication model whichprovides a controlled communication facility between extensions and the base system.An extension is defined in terms of events and event handlers. An event is a messageannouncing a change of state or a request to a service. Practically, an event is an entrypoint in the module defined in Modula-3, its is defined granularity at the procedure call.An event is an indirect invocation dispatched to its destination by the event dispatcher,that can control the binding. This extension model allows fast and fine-grained ser-vice extension, enabling applications to define customized interfaces. Extensions areinstalled in the system in two steps, first the extensions is linked into to kernel and inthe second step the extension registers handlers with events.
The SPIN microkernel provides three mechanisms of adding an extension to theruntime system: spindle to event association (dynamic linker), verification at installtime (safe language features) and running spindles at an event (event-based invocationsystem).
Although SPIN relies on a type-safe language, only code that needs to be insertedinto the microkernel needs to be written in this language - Modula-3. A drawback ofsuch a system is its ties to this language as well as the runtime check overhead that thislanguage implementation implies.
�������������������� ��������������
�������������� ������������������������ ����������
���������� ����������
������������������������
microkernel
user−level
Ver
ifie
r &
Com
pile
r
kernel−level
clie
nt a
pplic
atio
n
clie
nt a
pplic
atio
n
syst
em s
erve
r
Communication
Installing a spindle
Spindle System resource
user
−le
vel s
erve
r
Figure 2.2: Basic structure of services on the SPIN microkernel
27
Figure 2.3: Comparaison of communication in traditional microkernel server with par-titionned service in SPIN
2.2.3 Exokernel
Exokernel (Engler et al. [14]) is an operating system architecture developed atMIT that adresses the problems of limitation of performance or flexiblity in traditionaloperating systems by providing application-level management of physical resources.Exokernel pursues the concept of µ-kernels one step further - the kernel is merely anabstraction of the underlying hardware and provides only a bare minimum of mech-anism to protect resources. Several prototypes were implemented, Aegis (exokernel)together with ExOS (library operating system) is the one described here.
In exokernel architecture, a small kernel securely exports a hardware abstractionthrough a low-level interface to untrusted so-called library operating systems. Theidea behind exokernel is to give library operating-systems maximum freedom manag-ing physical resources while protecting them from each other. (This could be done byproviding a complete virtual machine for each application, but this approach suffersfrom bad performance) Exokernel separates protection of resources from their man-agement, the library operating system is intended to implement the management of agiven resource. However, some basic management mechanisms need to be provided bythe exokernel to the extent required by protection (management of allocation, revoca-tion and ownership of resources). The tasks of an exokernel are 1) tracking ownershipof resources 2) ensure protection by guarding all resources usage or binding points3) revoking (removing) access to resources. These tasks can be implemented as inAegis with three basic mechanisms: 1) secure bindings between resources and resourceowners/users 2) visible resource revocation protocol, enabling application libraries ontop of the exokernel to participate in resource revocation 3) abort protocol, the kernelbreaks the resource binding of an uncooperative application.
A similar approach to exokernel is pursued by Deimos (Dynamically Extensi-ble Incrementally Modularized Operating System, (G.Coulson and M.Clarke in [11]).Deimos doesn’t provide a kernel, only a Configuration Manager. Traditional kernel ser-vices and application specific services can be implemented as building blocks loadedby the Configuration Manager. No abstraction nor any mechanism other then the CMare provided.
An architecture like exokernel benefits from aggressive customization at user-level,at build-time, yet still it needs to design and implement some dynamic reconfigurationmechanism.
As concluded by Liedtke in [32]: "Still debatable is whether Exokernel’s nonab-
28
stractions, SPIN’s kernel compiler, L4’s address-space concept, or a synthesis of theseapproaches is the best way forward."
2.2.4 Vino
VINO (as introduced by Seltzer, Small et al. in [37]) is an extensible operatingsystem developed at MIT. It was designed to provide applications greater control overresources with focus on protection. VINO is highly modularized, even simple policiesare implemented as methods, which allows fine-grained extensibility, at the level of afunction call.
Extensibility in VINO can be done in two ways: 1) method replacement or 2) anapplication can register handler to a specific kernel event (such as a network connectionevent) and implement a reaction to this event. Extensions in VINO are called grafts.
As stated by Seltzer, Small et al. in [34], the kernel needs to be protected from twotypes of abuse that could be performed by extensions and proposes two mechanisms inorder to guarantee kernel protection:
- Memory misuse Indeed, extensions and kernel share memory and an extensioncould either access forbidden memory or call forbidden functions and corruptthe kernel.
VINO implements Software fault isolation (SFI) in order to prevent this kindof corruption. SFI, as described by Wahbe et al. in [40], consists of two steps.First, the untrusted extension code is loaded into its own fault domain, a logicallyseparate part of the kernel address space. Second, the code is changed so that themodule cannot write or jump to an address outside of its fault domain.
- Resource hoarding Grafts can consume system resources, such as physical mem-ory. If they would hold them over long intervals or allocate excessive amounts,it could cause serious dammage. For example a graft could acquire locks andnever release them.
In order to control the execution and resource use of extensions, the kernel im-plements a lightweight transaction mechanism (that only guarantees AtomicityConsistency Isolation properties). Resources are time constrained and the trans-action system provides an "undo" capacity. Each extension invocation is run ina transaction, that is aborted on failure (if monopolizing resources for example).The abort mechanism "undoes" all actions taken by the invocation.
A drawback of SFI is the overhead of the checking executed each time an "unsafe"instruction is encountered, as well as the overhead cause be the transacation mecha-nism. As stated by Seltzer in [34] transaction costs are relatively high, however inmany cases by allowing applications to modify the kernel, the time gained more thancompensates for the overhead of the mechanisms. In other cases, the gain in flexibil-ity would be a sufficient compensation, whereas in some cases the costs and thus themechanism would be totally inacceptable.
29
2.2.5 Apertos and other reflective OS
Apertos as described by Yokote in [42] is a reflective operating system based onthe concept of meta-objects and meta-spaces. It originated from researches around theMuse OS at Sony and later these concepts were pursued by the MetaOS project (Yokote[42], Horie et al. in [23] and [24] ). Apertos introduced a new paradigm which allowsapplications to change their semantics at runtime.
These systems are articulated around two main ideas: reflection and meta-objects.Reflection is the ability of a system to maintain and use a representation of itself.
The system can access, reason about and alter its own interpretation. Basically it is atwo-tired architecture, the meta-level encapsulates a representation of the informationcontained at the base-level. This principle can be extended recursively at an arbitrarylevel, the meta-level having another meta-meta-level..
In Apertos, an application must be explicitly structured as a set of objects. An ob-ject is a container of information and provides a service to their environment, whereasa meta-object defines the semantics of its behaviour, a policy (e.g. non-functional re-quirements). Each object corresponds to some implementation decision e.g. for mem-ory management. An object has a group of meta-objects associated to it. A meta-objectis an object, so recursively, a meta-object can have a meta-meta-object associated to it,building a meta-space. A reflector represents this meta-space. Interaction betweenobjects is achieved through a terminal object, called metaCore, which can create, dis-patch, destroy a meta-object and forward interrupts to them. This approach permitsto migrate easily an application with its execution environment (collection of objectsand a meta-space associated to it) to another machine. The concepts of Apertos aresummarized in the figure 2.4.
Dynamic reconfiguration in Apertos is also achieved through meta-space migration,associating an object space to another meta-space. For example to make an objectpersistent, we migrate it to a meta-space with persistence.
MetaOS (Horie et al. [23], [24]) addresses some issues not resolved in Apertos, inparticular MetaOS introduces another mechanism for dynamic reconfiguration, whichis secure and doesn’t rely uniquely on meta-space migration. Contrary to Apertosmeta-object, which has only a functional interface, each meta-object in MetaOS hasthree types of interfaces, one functional and two meta-interfaces (declarative and im-perative). The declarative interface allows to choose a policy from a predefined list ofpolicies. And the imperative interface allows to introduce new policies through a con-trolled manner (trusted meta-space manager). Furthermore, Apertos associates a threadand an address space to each meta-object, which makes communication too costly dueto context-switch overheads. MetaOS associates a thread to a meta-space (a group ofmeta-objects)
2.2.6 MMLite
MMLite (J.Helander and A.Fiorin, [22]) is a modular system architecture, that pro-vides a collection of object-based components, assembled dynamically into a full appli-cation system. Components can be selected at compile time, link time or run-time. Thearchitecture is aimed to environments, where general purpose approach is not applica-
30
Figure 2.4: Apertos concepts: relationship between objects, meta-objects and meta-spaces
ble or is expensive, as in embedded control systems, digital cell phones and networkinginfrastructures or programmable peripherals and micro-controllers.
MMLite components export their methods through COM (Component Object Model)interfaces and are made available by registering in a namespace. Namespaces are usedto let applications gain access to services provided by other components. Each objecthas a virtual method table and a method table pointer to it, this enables, among otherthings, late binding or transparency through proxies. Proxies are used to communicatebetween different address spaces (can be distributed) and marshalling (unmarshalling)messages used to communicate.
In MMLite the dynamic reconfiguration process is called mutation. Associated toit, the thread, that performs the mutation task is called mutator and is responsible forstate translation to the new component and the coordination with worker threads andother mutators requiring some synchronization mechanisms. These can be divided intothree groups: 1) mutual exclusion - mutation cannot happen while a worker thread stillexecutes in the object 2) transactionnal (atomicity property) - workers affected by themutation are roll-backed 3) "swizzling" (ie cheat) - suspend the workers and modifytheir state after mutation to reflect changes.
Together with K42 (see below), MMLite is the only system to address dynamicreconfiguration explicitly. However the mechanisms proposed seem to be complex andnot described in any publication.
2.2.7 K42
K42 is an open-source research kernel targeted for cache-coherent 64-bit multipro-cessor systems developed at IBM Thomas Watson Research Center (Soules et al. in[38], see K42 IBM web-site [26], see also K42/Tornado web-site [27] at Universityof Toronto). K42 is designed in an object-oriented language, where each component(called building block in K42 terminology) corresponds to an object. This technologypermits the customization of the K42 system. A system needs to provide two mech-anisms to support online reconfiguration. These are interposition and hot-swapping.Interposition consists of wrapping a component and extending its functionnality withcode that executes before the call to the component and after the call. Hot-swapping
31
dynamically replaces a component.In order to support these two mechanisms, the system needs to possess four capa-
bilities: 1) encapsulation of data an functionality, currently at component bounderies2) it must be possible to achieve a quiescent state of a component e.g. ability to stopthe component 3) a state transfer mechanism 4) it must be possible to modify externalreferences to a component.
Hot-swapping uses all four capabilities, whereas interposition relies only on theforth one to redirect external references to the interposed code/component, in K42 acaller access the components through object translation table, where the actual pointerto the component is stored. In order to interpose some code to the component, thesystem only needs to change the pointer in the object translation table and update ref-erences of the interposer.
K42 exploits the event driven nature of an operating system and each event (ie in-terrupt or a system request) is serviced by a new system thread. These system threadsare short-lived and no blocking is authorized at system level (wait is done with a call-back mechanism). Requests are divided into epochs by partitioning the threads intogenerations and it is possible to determine if the threads belonging to a given gener-ation have terminated. All new threads are associated to the current generation. Thefollowing algorithm is used to determine when all current threads have terminated.
i := 0while (i < 2)
if (non-current generation’s s count = 0)make it the current generation
elsewait until it is zeroand make it the current generation
i := i+1
The process of switching the current generation is called generation swap.The component hot-swapping in K42 builds on interposition - in the first time me-
diator is interposed the component to be swapped. To ensure, that the component isin quiescent state (i.e. that there are no active calls in it, corresponds to our notion ofstable state), the mediator goes through three phases: forward, block and transfer, seefigure 2.2.7 for illustration.
In the first phase, each call to the component is forwarded and tracked. The me-diator waits for untracked calls to terminate. To achieve this, a request is made to thegeneration mechanism at the beginning of the forward phase to establish a quiescentstate. After two generation swaps, the generation mechanism calls back and all un-tracked calls are guaranteed to be completed. The mediator enters the block phase,where it blocks all incoming calls and waits for the tracked calls to complete (againwith the help of the generation mechanism), except of recursive calls that are allowedto proceed until they terminate completely. When all tracked calls have completed, thecomponent is in the quiescent state and the mediator begins the transfer phase, transfer-ring the state from the old component to the new one, updates object translation tableand forwards blocked calls to the new component, discarding the old component.
32
Figure 2.5: Dynamic replacement of a component in K42 (hot-swapping in K42 termi-nology)
The K42 approach tends to a ’pseudo’-synchronous approach, with generationswap being an "instant" as in synchronous systems. We could push the concept furtherby exploiting the event-driven nature of an operating system and consider synchronousprogramming for building an operating system. See more on synchronous program-ming in Appendix A.
2.3 Summary
In order to compare and classify the operating systems reviewed in this section wepropose the following classification system, based on different dynamic reconfigurationcapabilities (components in this paragraph denote building blocks (entities), that can besubject to reconfiguration).
Add a component The capacity of the system to add new components to thecurrent configuration.
Remove a component This refers to the capacity to remove a component, in-cluding the ability to stop a component.
Replace a component The most interesting aspect of the dynamic reconfigura-tion. With respect to state transfer we distinguish two types of a replacement:
– without state transfer– with state transfer The format of the state passed between the components
must be the same, or the system implements a mechanism that transformsthe format of the old component’s state to the new format of the new com-ponent.
The following table 2.3 classifies the reviewed research operating systems accord-ing to these issues.
33
CapabilitiesM
icro
kern
els
SPIN
Exo
kern
el
Vin
o
MM
Lite
K42
Add X X X X X XRemove X X X X X XReplace without state transfer * * *
with state transfer (same format) X Xwith state transfer (difference format)
X - possible, * - not specified but possible (including ad-hoc mechanisms)
Table 2.2: Summary of Adaptable Operating Systems
34
Chapter 3
THINK
3.1 Introduction
THINK 1 is a component framework for building flexible component-based opera-ting systems. These systems may vary from distributed systems to embedded systemswith strict restrained environment requirements. THINK (described by J.F. Fassinoin [16] and in [15]) provides a minimal set of abstractions to the system programmerdefined in interfaces, implemented by components. The underlying hardware is rei-fied as components. The model doesn’t impose any granularity of components. Forexample a video driver can be a component as well as an interrupt handler. THINKprovides a uniform and highly flexible binding model, so we can assemble any kind ofoperating system ’à la carte’, by putting the right components together. Furthermorethe framework is open and extensible, anyone can define new components with newinterfaces.
3.2 Fractal Component Model
THINK implements the Fractal component model developed at France Telecom -Division R&D 2 and INRIA within the Objectweb consortium (see Stefani et al. in [8],the Fractal specification [10], and the ObjectWeb site [17]).
The Fractal component model was designed to meet requirements of complex soft-ware systems, while imposing no restriction on what components should implement.Fractal is defined as an “extensible system of concepts” (Fractal Specification [10],represented through APIs that a component may implement. The set of specificationscan be organized in increasing order of reflective capabilities (introspection and inter-cession). At the lowest level, a component doesn’t provide any control interfaces tothe system, the next level provides means for introspection of interfaces being imple-mented. In the next level, a component provides interfaces for inspecting the content of
1THINK acronym stands for ’Think is not a kernel’.2former France Telecom R&D
35
a component, also called “configuration” level in Fractal. In Fractal, a component canbe made out of other components, connected together with bindings, so at this levelthe component can choose to provide interfaces to control its set of sub components,bindings and so on.
For more information on the Fractal component model and on a Java implementa-tion called Julia, see the documentation at the Objectweb web site ([17]).
In the Fractal component model a component is a software entity, which possiblyencapsulates some state and provides some services through component interfaces, thatact as access points. A component can require services by the means of an interfacerequirement. There is no restriction on how many interfaces a component can provideor requires.
An interface defines a set of operations that can be invoked on the component.Fractal is a language independent model, therefore interfaces are described in an Inter-face Definition Language (IDL), the Fractal IDL and for each implementation languagethere is a mapping to the programming language, which may also provide a standardcalling convention if the interface is not present in this language. For more detailedsyntax of Fractal IDL, see the Fractal component model Specification [10].
Internally a Fractal component has two parts, a controller and a content. The con-tent is "under the control" (see bellow) of the enclosing controller. At the lowest levelof capabilities, a component doesn’t provide any means for introspection or interces-sion. Such a component is called a base component. A component, that provides onlyinterfaces to introspect their external features is a primitive component (the Compo-nentIdentity interface) and a component that exposes its content for inspection is calleda composite component.
A Fractal component can contain a finite number of other components (called subcomponents) we speak about Composition, thus the Fractal Component Model is re-cursive, without any restriction. Internal interfaces (ported by the sub-components)may be exported by the controller and become visible outside the composite. A com-ponent may be shared by several distinct components. The semantics of the resultingconfiguration is then determined by a controller, that encloses all components in theconfiguration.
A Fractal component can have two types of interfaces: functional - interfaces thatthe component provides and that it requires - and non-functional (also called control)interfaces defined by the Fractal Component Model. These interfaces serve configu-ration, introspection, reconfiguration.. The Fractal Component Model defines severalnon-functional interfaces, like AttributeController, LifeCycleController, BindingCon-troller ... (see the Fractal Specification [10]). The set of control interfaces implementedby a component is modular and extensible, one may decide what interfaces a compo-nent will provide and anyone can add its own control interface suitable for an applica-tion.
The control behaviour of a component is implemented by the controller. Howeverthe control capability is not limited by the model. In particular, it can provide a rep-resentation of the component’s sub components or intercept incoming and outgoing
36
operation invocations. The controller can also superpose a control behaviour to thebehaviour of the component’s sub components, as suspending or resuming executionof the sub component or redirecting calls etc.
The communication between component interfaces is represented with bindings.Required interfaces can be bound to provided interfaces of the same type (or a subtype).
The Fractal model defines an optional simple type system, where an interface de-fines also a type. A component’s type is the set of component interface types.
...
......
control interfaces
provided interfacesrequired interfaces
controller a sub-componenta binding
membrane
Figure 3.1: Fractal concepts - primitive and composite components, their interfacesand bindings
3.3 THINK Framework
THINK is a C implementation of the Fractal component model for building component-based operating systems. Kortex is a library of kernel components, that offers severalmodels of threads, memory management and process management services. Thereare low-level, machine dependent components and high-level components that can bereused in system configurations on different machine architectures. Additionally, theKortex library implements different forms of bindings.
The THINK framework includes IDL (Interface Definition Language) files describ-ing interfaces defined in Kortex, C sources that implement these interfaces and theTHINK ADL (Architecture Description Language) - a mean to describe how interfacesare mapped to components (what interfaces a component implements) and how theyare connected. In fact an ADL exists also in Fractal, based on XML. The THINK ADLis more a "user-friendly" ADL with some THINK specificities not included in the Frac-tal ADL. In THINK the ADL is used to describe the configuration at boot time and togenerate ’glue’ code that connects components together, the infrastructure.
Furthermore the framework includes examples of kernels, tools to build a runningkernel from an ADL description and the corresponding C sources. The build processincludes some verifications and glue code generation from the ADL, as already seen.
37
3.3.1 Architecture Description Language
To facilitate the process of assembling components, the architecture of the resultingsystem is described in terms of a typed ADL (Architecture Description Language).The THINK ADL allows to describe interfaces, the components implementing them,bindings and component controllers. Note that the ADL describes a static aspect of thesystem.
The THINK ADL allows to define types of components. The type is a set of in-terfaces that a component must provide or requires. It is a simple type system, wherethe new types can be derived from existing ones, adding interface declarations. Defin-ing types is useful, when defining several implementations for one type of component,for example a type FileSystem can be implemented by the component Ext2FS and bythe component JournalFS, both providing the interface FileSystem but implementingdifferent file systems (IBM’s jfs and Linux’s ext2).
For example to define new types and extend existing ones, one would write:
type RootType {provides activity.api.Main as main
}
type ClientType extends RootType {requires video.api.Console as cons
}
This defines two types, RootType that provides the interface activity.api.Main andClientType extending RootType by requiring the video.api.Console interface.
Defining a primitive component in THINK ADL goes as follow:
primitive helloworld {provides activity.api.Main as mainrequires simple.api.Register as regrequires video.api.Console as consattributes positionskeleton hwBase_code.c
}
Note, that a declaration of a primitive component defines implicitly a new type, thatthis component implements, the last declaration is equivalent to the following:
type hwBaseType {provides activity.api.Main as mainrequires simple.api.Register as regrequires video.api.Console as cons
}
primitive helloworld implements hwBaseType {attributes positionskeleton hwBase_code.c
}
38
Finally we can define a composite component, that contains some sub componentsand defines bindings between interfaces provided and required by those. For a com-posite component we must also define a controller - a Java class, that generates thenecessary glue code of the composite, including control interfaces.
composite hwKernel implements activity.api.Main {contains console =
powerpc.macintosh.video.lib.screencontains hw = helloworldbinds this (activity.api.Main) to hw.mainbinds hw.cons to console (video.api.Console)binds hw.reg to register.regcontroller org.objectweb.think.controller.Static
}
This ADL excerpt is taken from the HelloWord example, that is illustrated in the figure3.3. See Appendix B for the complete HelloWorld example.
However, an ADL describes only a static view of the system, for example the pro-cess of dynamic reconfiguration can’t be described only in terms of the ADL (see ourproposition for describing dynamic reconfiguration in the next chapter).
3.3.2 Generation Chain, Tools
The build a THINK kernel can be split into well defined steps, see figure 3.2. Thetools, that assist this process are written in Java to be platform independent.
First of all, a number of interfaces described in the Fractal IDL are provided in theKortex library. These interfaces are parsed and implementation language dependentheader files are generated following the mapping rules from the Fractal componentmodel to the THINK implementation pattern (here the implementation language C).
In the next step a complete ADL description is built (out of the source kernel ADLand small pieces of component descriptions in ADL included in the library). This re-sulting tree is parsed and if needed, some component glue code is generated (in the caseof THINK, it is C source code). At this step, the framework generates the component’scontroller code by calling the associated (in the ADL, see above) Java class. This stepincludes some verifications, for example checking if all required interfaces are boundcorrectly (to provided interfaces of the same type..).
The generated header files, the generated glue code and the actual componentsimplementations are then compiled with a C compiler that fits the target’s hardware.The component’s functional implementation and the generated code are closely tiedand a naming convention is defined to fit them together.
The final step is left to the linker, that assembles the object code generated in theprevious step into a running kernel.
3.3.3 A simple HelloWorld kernel
The figure bellow shows a simple THINK kernel, the purpose of which is is to printthe line "Hello World!" on the screen.
39
Figure 3.2: The THINK generation chain.
Every THINK kernel has a general base composite, here the hwppckernel, con-taining the boot component and the actual kernel, here helloworld. The bootcomponent is responsible for bootstraping the operating system on the target machinearchitecture. It then activates the kernel by calling the main() procedure of the Maininterface provided by the hwkernel component, our example kernel.
The hwkernel contains two components bound together: console - the consoledriver, and helloworld that uses the console to print the line "Hello World!" andstops.
Figure 3.3:
For the complete HelloWorld example, see Appendix B.
40
Chapter 4
Dynamic Reconfiguration inTHINK
This chapter presents our proposition of a dynamic reconfiguration mechanism forthe THINK framework described in the previous chapter. We first focus on goals anddesign principles of such a mechanism and then on its implementation fitting the actualimplementation of the THINK framework.
4.1 Design Principles
When designing a dynamic reconfiguration mechanism for the THINK framework,we pursued several goals:
? design a general flexible mechanism that supports all possible models of dynamicreconfiguration, as introduced in the previous taxonomy (see Chapter 2),
? the mechanism should allow a fine-grained reconfiguration,? this mechanism should be optional - components, that do not need to be recon-
figured dynamically should not be influenced (note that a controller is a part of acomponent, so indirectly it can be subject to reconfiguration),
? the mechanism should have minimal (or none) impact on the implementation ofthe functional part of a component,
? the run-time overhead should be minimal.
As described earlier (see Chapter 3), THINK is a component-based operating sys-tem framework with components as its building blocks. It comes naturally to definedynamic reconfiguration at the level of a component’s controller - the controller imple-ments the necessary mechanism needed to reconfigure dynamically the encapsulatedcomponents. The reconfiguration primitives include removing, adding or replacing acomponent in the scope of the controller (see Fractal Specification, [10]). The con-troller also controls the state transfer between the old and the new component, at the
41
least it may initiate it (see more in our proposition bellow). Only components that needto be reconfigured at run-time need a reconfiguration capable controller.
Component-level reconfiguration permits a fine-grained system reconfiguration, atthe level of component’s interfaces. Indeed, when reconfiguring at the component-level, we may replace the existing component with a new component providing a newinterface. Here the type system, as introduced in the Fractal Component Model can beconsidered to allow reconfiguration only of compatible component types (consequentlyinterface types with respect to the Fractal type system, as introduced in chapter 3).
As seen in the Fractal Component Model, a component may provide a degree oftransparency. The Fractal Component model defines several interfaces to inspect thecomponent’s contents (sub-components, interfaces, attributes or bindings) and controlthe component’s life cycle. We go in more detail on these interfaces when describingthe implementation of the reconfiguration mechanism.
With the component reconfiguration we propose a dynamic reconfiguration mech-anism that respect all design issues of dynamic reconfiguration, with respect to thetaxonomy introduced in the chapter 2. These issues are detailed below.
Type
Typically a kernel constructed from the THINK framework is a set of intercon-nected components, as shown in the figure 3.1. The scope of the reconfiguration is thecomponents controller, that implements the actual mechanism. The interface providedby a component may be changed by the same means, an existing controller providinginterface A may be replaced with a new component providing interface A’, where A’ isa subtype of A.
Components are connected together with bindings, so to achieve a reconfigura-tion at the architecture level, the controller changes the bindings between the encap-sulated components. Changing bindings also allows a geographical reconfiguration ofthe system (the architecture remains the same). The binding to this component must bechanged to enable the communication with the remote component. The binding is thena proxy. However the distribution is out of the scope of our proposition.
Reasons
With the mechanism introduced above any "reason" of reconfiguration is possible,within the scope of a component. Replacing a component may satisfy a correction or aperfection of a component’s implementation (corrective and perfective reason). Moreis needed when reconfiguring for adaptive or extending reasons. The controller mayalso reconfigure bindings between components, typically when adding a new device,the component implementing the device driver must be bound to the latter.
Initiator
The design of the THINK framework and of the reconfiguration mechanism doesn’timpose any constraint on who should initiate the reconfiguration process. Howeverevery type of initiator needs more system support then just the base reconfiguration
42
mechanism. Typically, an automatically reconfigurable system needs some diagnos-tic gathering about the component (or system) functioning and some reconfigurationdecision heuristics. On the other hand, a humanly reconfigurable system needs somemeans to communicate with the user. All these scenarios are allowed by the generalreconfiguration mechanism as we propose it.
Reconfiguration Management
As described in the taxonomy (in the chapter 2) the reconfiguration mechanism canbe split in parts, some being executed on a supportive network infrastructure on be-half of the device running the operating system instance. A device with the operatingsystem is standalone if the controller implements the complete reconfiguration mech-anism. Although the controller may implement a communication protocol with thenetwork infrastructure, some parts can be performed on remote systems. Typically thenetwork infrastructure would perform the verification on behalf of the device’s THINKoperating system.
The following table 4.1 summarizes the design issues of the above introduced dy-namic reconfiguration mechanism.
To complete the above proposition we introduce a formalism to describe the currentconfiguration of the system and a formalism to describe the reconfiguration process.These are detailed in the following section.
4.1.1 Dynamic reconfiguration description
The goal of this proposition is to provide a description of the operating systemconfiguration. The system configuration description is used as a basis of the dynamicreconfiguration description - a set of well-known rules, that transform the current con-figuration expression into a new one. This is the foundation of the verification systemand a mean to automate the reconfiguration process.
It proved that such a description already exists in the form of the ADL descriptionof the system architecture. However, for commodity reasons we defined a simplersyntax, that can be found in Appendix C. This is provided as an extension to our workin order to exploit the proposed mechanism, indeed a deeper research on this subjectwould be required to propose a complete formal description.
Example
The HelloWorld example system shown in the figure 3.3 (in the previous chapter)would be described with the following expressions:
system = hwppckernel[ νBoot boot[ b<Boot> ] Main | hwkernel’ ]
hwkernel’ = νMain hwkernel[ νMain helloworld[ m<Main> ] Console | νConsoleconsole[ cons<Console> ]; (hwkernel<Console>, Console<Console>) ]
43
TypeImplementation component replacement, identical inter-
facesInterface component replacement, with a new inter-
faceArchitecture modifying bindings between componentsGeography relocating components to different sites
and modifying bindings by providing prox-ies
ReasonsCorrectiveExtendingAdaptivePerfective
no constraint imposed, all four re-configuration reasons possible
InitiatorHumanApplication (user/kernel -level)Automatic
no constraint imposed, all three ini-tiator types are possible to imple-ment
Reconfiguration ManagementStandalone complete reconfiguration mechanism im-
plemented in the device operating systemNetwork infrastructure reconfiguration split, some steps taken in
the network infrastructure on behalf of thedevice
Table 4.1: Dynamic reconfiguration in THINK - design principles
Reconfiguration rules
The ADL or our simplified syntax describe only a static view of the system config-uration. In order to reconfigure the system (modifying its configuration description),we propose to introduce transformation rules that correspond to a particular reconfigu-ration step. Together with the above description, the rules provide a basis of a formalverification (proof). For example we can verify the type conformance of the new andthe old components. However this proposition is on the limit of the scope of the workundergone in this project, so we will content ourselves by giving an outline of theconsidered mechanism.
The system (to be specified, where exactly) would implement only a checker thatmaintains the current configuration expression. The system accepts a new configura-tion description and if one of the transformation rules can be applied, it performs thereconfiguration and updates the current configuration, otherwise the reconfiguration isrejected (recall, that integrity property is enforced by the reconfiguration mechanism).
Note that a reconfiguration is valid, only if obtained by a applying exactly onetransformation rule, because the verification that an expression can be reduced to an-other according to a given grammar is complex and we want to design an efficient
44
mechanism. We call this primitive reconfiguration, reconfiguration obtained by apply-ing exactly one transformation rule. Complex reconfigurations can be achieved as a setof primitive reconfigurations applied to the system.
As an example we propose to reconfigure the HelloWorld kernel by replacing thecomponent console. The rule that permits us this reconfiguration is the following:
component[ Φ ] → component′[ Φ ]
where Φ is an abbreviation of the constant part of the configuration description. Ap-plied to the HelloWorld example, this would be:
console[ Φ ] → myconsole′[ Φ ]
4.2 Implementation
In this section we propose a realization of the above reconfiguration mechanismin the THINK framework. We first focus on the actual implementation of the THINKcomponent and the controller providing the non-functional interfaces defined in theFractal Component Model. A state transfer mechanism is proposed subsequently. Ageneral reconfiguration mechanism with two possible implementations of achieving astable state is presented afterwards, followed by its evaluation.
The following figure (4.1) shows the implementation of an interface by a compo-nent in THINK. The components A and B implement the interface foobar providingtwo methods foo() and bar. Each component has its own data. An interface refer-ence (typically a memory location) is needed to access a particular component. Thisinterface reference points to an interface descriptor holding a pointer to the implemen-tation table (meth) and another pointer to the component data (data). All componentsimplementing the foobar interface have their meth pointer pointing to the same ta-ble of interface methods with the implementations (the methods are implemented onlyonce). In the THINK framework every interface method accepts component specificdata as parameters.
bar implementation
meth
data data
foo
bar
...
interfacereference
interfacedescriptor
table of interfacemethods
foo implementation
meth
data data
A Bfoobar
foobar
Figure 4.1: Implementation of a component in the THINK framework, use of indirec-tions.
To resume: The interface reference to foobar of the component A is available.To call the method foo() we do the following:
45
1. dereference the interface reference (access to the interface descriptor)2. dereference the meth table pointer3. dereference the foo() function pointer found in the table4. call the actual implementation of foo() with data passed as parameter
Components and interfaces are implemented with the use of indirections (functionpointers in C). A call to a service provided by a component’s interface comes with acost of three indirections, instead of a simple inline call.
Consider composite components, where interfaces from the sub-components areexported by the controller. In the Fractal Model nothing is stated about the implemen-tation of the composite components. In Kortex (as in Julia) the bypass technique isused to optimize the access to interfaces of sub-components, see figure 4.2.
...interfacereference
interfacereference
a) model view b) Implementation
...
Figure 4.2: Accessing interfaces of sub-components.
The set of Fractal interfaces provided by the controller define the programmingmodel from the point of view of dynamic reconfiguration. A component must imple-ment the following primitive interfaces in order to enable its internal manipulations insight of dynamic reconfiguration. Note, that these can be generated automatically bythe THINK generation chain. The programmer of a component must only participatein the state transfer implementation by providing means of exporting, importing andeventually converting state of the component.
• Component (ComponentIdentity in the older specification) - this is theaccess point to the component’s interfaces.
• ContentController allows manipulating the contents of a composite (sub-components)
• AttributeController - set() and get() methods for accessing at-tributes of a component (generated automatically)
• BindingController allows manipulating bindings between components con-tained in the composite
• LifeCycleController - interface to control the execution of the compo-nent, provides two primitives: start() and stop()
4.2.1 State transfer
The design principles presented above allow us to propose two different strategiesfor state transfer between components: 1) using the formal reconfiguration description
46
and attribute mapping between components (this assumes, that the internal state of acomponent is entirely captured by its attributes) or 2) leaving the state transfer controlto the new component. These two strategies are coexistent.
The first approach uses the formal reconfiguration description and the associatedtransformation rules to map attributes (may be complex) from the old component tothe new component. For example, suppose we want to replace the component A withthe component B. The description may define attribute foo as being "owned" by thecomponent A. The transformation rule (to be specified) indicates to the system, thatfoowill be mapped to bar of the new component B. To access these attributes, Fractaldefines a non-functional interface AttributeController that defines methodsgetFoo() and setFoo() for the attribute foo in a component. As seen in theprevious chapter, these interfaces can be generated automatically by the generationchain of the THINK framework.
An advantage of this approach is the formal basis provided by the description (see4.1.1) and the verification system. However, this approach doesn’t allow any complextransformation of the state format, because each step of the transformation correspondsto a simple load/save operation on the attribute.
To overcome this drawback, the second proposed approach leaves the control of thestate transfer to the new component. Suppose that we want to replace the component Awith the component B. We extend the Fractal Component Model with a new interfacecalled StateController with two methods getState() and setState()that manipulate a zone of memory in a format convenient for the given component’suse. This memory zone is opaque to the rest of the system. It is up to the componentprogrammer to implement these interfaces.
For the purpose of state transfer and only during the transfer we introduce a trans-formator component, that understands the formats of the old component state and thenew component state.
1. The transformator component is loaded.2. The transformator gets the state exported by the component A,3. Converts it to the new format required by B4. Inserts it to B.5. The transformator component is then unloaded from memory.
However, note, that B can actually contain the transformator. The drawback is thatthe code is used only once, at reconfiguration time and it increases the component’smemory footprint.
4.2.2 Reconfiguration Mechanism
For the purpose of dynamic reconfiguration, we define a new interface in the THINKframework called Reconfiguration:
interface Reconfiguration {int request(string description);void resume();
47
int cancel();}
To start a reconfiguration, the initiator submits the new reconfiguration descriptionvia the request() call. Similarly, an ongoing reconfiguration can be cancelled bycalling cancel(). The resume() method is a callback passed to a controller toavoid blocking when waiting for stable state.
We shall refer to the component implementing this interface as to ReconfEngine.This component implements the reconfiguration policies and the verification of the re-configuration. Moreover ReconfEngine maintains the actual system configuration. Asalready seen, this configuration serves verification purpose, but also retrieves compo-nents when ready to start the reconfiguration. The following figure (4.3) illustratesthe way ReconfEngine is integrated in the THINK framework on the example of theHelloWorld kernel.
holding the systemconfiguration:
system part toreconfigure
ReconfEngine
a[ i<u,v> | j<x,y> ]
a reconfigurable THINK kernel
Figure 4.3:
Furthermore, we propose to extend the LifeCycleController interface withtwo methods:
• suspend() method (reconfiguration request) - requests the controller to putthe controlled component into a stable state. This is applied recursively to thesub-components, if the component is a composite.
• resume() (reconfiguration cancel) tries to cancel the ongoing reconfigurationand resume normal activity in the component. Again, this applies recursively tothe component’s sub-components.
• Although the Fractal Specification doesn’t specify any particular semantics of thestart() andstop() operations already present in the LifeCycleController,we prefer to keep the intuitive semantics of stopping and starting the componentwithout any condition. This may be useful for temporarily stopping the compo-nent, without need to reconfigure.
The proposed reconfiguration mechanism works as follows:
1. An Initiator (as described in the taxonomy) requests a reconfiguration by callingrequest() on the ReconfEngine with the new configuration as an argument.
48
2. The ReconfEngine component verifies if the reconfiguration can be performed,if not, it rejects it and stops. At this stage, the components and bindings toreconfigure are identified.
3. The ReconfEngine component binds to the control interfaces of the componentsto reconfigure (LifeCycleController,ContentController, StateController, ...).
4. On each component to reconfigure: the ReconfEngine requests a stable state bycalling suspend().
5. When this state is attained (see the two propositions bellow on how to implementa stable state), the controller calls back the ReconfEngine by calling resume()(passed as argument to suspend())
6. The ReconfEngine performs the actual reconfiguration:
(a) new components are loaded into memory
(b) and/or bindings are reconfigured (BindingController,ContentController)
(c) the state is transferred between components (using one of the methods de-scribed above) (AttributeController or StateController)
(d) no longer needed components are unloaded
7. The reconfiguration is terminated and the new configuration is saved
Stable state - Proposition I
Before a component can be swapped, in order to capture its internal state in a con-sistent manner, the system must ensure that the component is no longer in use - thatall activity in the component terminated. We called this state "stable" (see Introduction1.2).
To ensure this property we propose to interpose static proxies between the interfaceprovided to the outside by the component’s controller and the actual interface providedby the component (see figure bellow (4.4). We propose to generate these proxies au-tomatically as part of the THINK generation chain. These proxies must be includedin every component that could be reconfigured. Note that the proxies are transparent,the access to the component from the point of view of the user remains the same. Theproxies perform an additional control, here they gather the usage of the component.
The proxies interact with the LifeCycleController interface when a stablestate request is made. At first approach we achieve the stable state by counting theincoming and outgoing calls and when the counter is zero, no call is active inside thecomponent and the LifeCycleController can call back the ReconfEngine toresume the reconfiguration. This is how the stable state is implemented in Julia.
The drawback of this approach is the performance. This approach cannot make theuse of the bypass technique as seen earlier and in the worst case (nested components)the simple call to an interface which makes use of three indirections, is transformed to
49
meth
data
foo
bar
...
interfacereference
interfacedescriptor
table of interfacemethods
foo proxyimplem.
foobar
meth
datadata
foo
bar
...
foo implem.
proxy data
re�f
foobar
controller
the actualimplementationof the component
table of interfacemethods (proxy)
Figure 4.4: Implementing proxies in a component.
a chain of indirections, traversing all proxies (see figure 4.2). Furthermore, the proxiesoccupy a constant amount of memory size, which could be freed in theory.
Stable state - Proposition II
To overcome the drawbacks of the previous proposition, we propose an alternativeimplementation of the reconfiguration that is based on the K42 mechanism, as seenin 2.2.7 and K42 Online Reconfiguration [38]. This solution is more complex andrequires at least an implementation of a thread generation management component.Such implementation is out of the scope of the work undergone in the project, howeverwe will outline the global mechanism.
As in K42, we suppose that 1) system threads are short-lived i.e. they always termi-nate in a limited time and 2) system threads do not block (wait can be implemented as acallback). To attain a stable state, we use the notion of thread generation and generationswap introduced in K42.
In this context the stable state is reached in three steps:
1. When a reconfiguration request is made, the ReconfEngine component installsdynamic proxies interposed in the same way as static proxies. Contrary to theprevious solution, here the proxies communicate directly with the ReconfEngineand the extension of the LifeCycleController is not needed. In the firstinstance, the proxies let all incoming calls through and track them. (K42 forwardphase)
2. On a generation swap, all untracked calls are terminated. Proxies enter the blockphase, as in K42. All new calls to the component are suspended, only trackedrecursive calls are allowed to proceed.
3. On the next generation swap, all tracked calls terminated and the component is ina stable state, the reconfiguration can proceed with a state transfer as describedabove.
50
However when implementing this approach we face two major problems: 1) the ac-tual Fractal Component Model does not provide any formal support for proxies (neitherformal description nor semantics of proxies), hence the designer is free to implementthe controller as he wishes and 2) this approach supposes short-lived system threadsand non-blocking behaviour at system level, yet these properties are not met in thecurrent implementation of some THINK components.
4.2.3 An example scenario
Assume that we want to reconfigure a router. The scenario is illustrated in thefigure 4.5 below. We propose a simple router implementation with two compositecomponents: a stack composite implementing the network protocol stack, and acomposite that contains the routing tables and policies. Both components are sub-ject to reconfiguration, so both implement the control interfaces needed for this pur-pose. Note also the presence of the ReconfEngine component, that implements thereconfiguration strategy as already described.
Our initial router has support for the classic TCP/IP protocol stack, each proto-col implemented in a separate component. Bindings between these components arecontrolled by the encapsulating packet component.
Let us suppose we want to reconfigure this router as present in the figure 4.5 a)and add support for the SCTP (Stream Control Transmission Protocol, a transmissionprotocol on top of IP, rfc 2960). In order to perform this reconfiguration, we have toadd the SCTP component in the packet composite and alter the bindings of the IPcomponent. Let us suppose, that we also need to replace the implementation of the IPcomponent.
Hardware
network card
driver
ethernet
IP
stack
router
scheduler
mem
CPU MMU
UDP
TCP
ReconfEngine
Hardware
network card
driver
ethernet
IP
stack
router
scheduler
mem
CPU MMU
UDP
TCP
RE
STCP
a) before the reconfiguration b) after the reconfiguration
Figure 4.5: An example scenario: a router. (simplified schema, router componentnot described precisely and bindings inside the packet components are also left out)
Here are the reconfiguration steps that need to be performed in order to completethis reconfiguration.
51
1. Reconfiguration request to ReconfEngine, calling request()with the newconfiguration as argument
2. ReconfEngine calls suspend() on stack and IP.
3. the activity in the stack proceeds until a stable state is reached, this is detected bythe proxies of the IP and stack component. The global stable state is reached,when all components are in a stable state, suspended.
4. resume() of the ReconfEngine is called via the callback mechanism
5. ReconfEngine loads the new components, SCTP and the new IP
6. ReconfEngine initiates the state transfer between IP and the new IP com-ponent, by calling getState() (StateController) of the old IP andsetState() of the new IP
7. ReconfEngine can now unload the old IP component, it stops it first (callingstop() of the LifeCycleController)
8. ReconfEngine reconfigures bindings (via the BindingController inter-face of stack)
9. ReconfEngine calls resume() on stack and IP. SCTP is in not running,the ReconfEngine calls start() (LifeCycleController)
10. eventual pending calls are resumed
4.2.4 Evaluation
The different implementations are compared with regard to two criteria: size over-head of the component code induced by the mechanism (important in embedded opera-ting systems), compared to a bare component and the performance of the proposed re-configuration mechanism, measured with the induced overhead in time. This includesreconfiguration time - the time needed to complete the reconfiguration process andeventually a constant overhead at the call of a component, due to interface redirectionfor example. The overheads are compared to a normal execution, not in the reconfigu-ration stage.
bare component Proposition I Proposition IIsimple call 3 indir. (1 bypass) 6 indir. 3 indir. (bypass)call to a nested com-ponent at level n
3 indir. ( 1 bypass) 3n indir. 3 indir. (1 bypass)
reconfiguration time simple complex
Table 4.2: Time overhead evaluation
Although the second proposition is more complex and requires strong constraintson the system, it is more efficient from both points of view - memory size and run-time
52
Proposition I Proposition II
per component reference counter nonecode of the control interfaces (ContentController...)
per interface proxy (see table below) noneper system ReconfEngine component imple-
menting the Reconfigurationinterface
Table 4.3: Size overhead evaluation (only the constant size overhead is taken into ac-count)
Proxy
interface descriptora pointer to the table of methodsmetha pointer to proxy data
dataa pointer to the interposed interfacedescriptora pointer to the proxy data
table of methods one pointer per methodproxy code a function per interposed method
(management+forward call) "sev-eral" instructions
Table 4.4: Proxy cost
performance. However in order to manage the complexity of the whole reconfigurationmechanism we implemented the first proposition, which can be subsequently subjectto some optimizations. Indeed, the second proposition can be seen as an optimizationof the first (static vs. dynamic proxies) hence with strong system constraints.
53
Chapter 5
Conclusion
In spite of the promises of dynamic reconfiguration in embedded operating sys-tems and generally in any kind of operating system, the mechanism is far from beingexhaustively explored and well understood. To our knowledge, the mechanism is notimplemented in any industrial operating system. The research is still moving forwarddefining new goals for dynamic reconfiguration.
In the context of our work we proposed a model of dynamic reconfiguration in theTHINK framework. To implement this model we extended the Java tools provided inthe generation chain of the THINK framework. These extensions generate (C code)proxies and specialized component controllers. The glue C code generated by thesetools is completed with a generic C implementation of the component controller thatwe also implemented. In order to test our proposition(s) we developed a series of testscenarios, the most complex and interesting was described in the previous chapter (seefigure 4.5). We also considered to modify the current THINK implementation in orderto support our second proposition. We also proposed some extensions to the FractalComponent Model, however these may still evolve (in particular StateControlleror LifeCycleController).
5.1 Opened Issues
There are several issues that have not been addressed in our proposition. We pointthem out briefly in the following.
? The ReconfEngine component holds the current system configuration. Weneed to define a way to represent this information efficiently.
? In our implementation, no verification (type conformance, correctness of bind-ings..) is performedm, nor an exhaustive list is defined.
? Neither our proposition, nor implementation, stated where from the new compo-nents are loaded. This may already represent a degree of dependency vis-à-vis anetwork infrastructure.
54
? For the purpose of the state transfer between components, we also proposed amechanism to convert between different formats of the internal state of thesecomponents, the transformator component. We did not propose any imple-mentation, which would require more thought about this particular component,such as who programs it, how the internal state could be represented and more.
? The proposition is a model of a dynamic reconfiguration mechanism. Concern-ing the Initiator of the reconfiguration (2.1.3), nothing was stated about the poli-cies and mechanisms involved.
? It would be interesting to review the THINK framework implementation in orderto support our second proposition (see 4.2.2). We would have to asssure, thatall system threads are short-lived (which is not the case, see netactivityimplementation) and that the system threads do not block. This proposition alsorequires an implementation of the thread generation mechanism.
? To complete the above formalism, the transformation rules need to be completelydefined. For this purpose a naming language might be needed (for exampleFPath, which is an XPath like unpublished component address language).
? Optimization: As we already stated when evaluating our proposition, the imple-mentation of Proposition I (4.2.2) could be subject to aggressive optimization.
– Based on what criteria? We could consider performance of the reconfi-guration mechanism, performance of the system, memory footprint of thekernel and many more.
– How can we optimize the implementation of the mechanism in order toimprove performance? For example, a possible optimization for proxieswould be to reuse the calling stack, but this technique suffers from someserious drawbacks.
– Would be the optimization reversible? The optimization modifies the run-time representation that enables us to reconfigure the concerned compo-nent, thus loosing the reconfiguration capability of the optimized compo-nent.
5.2 Perspectives
We believe that new ways of structuring the operating system will have an impacton this mechanism. For example we believe that we can construct an operating sys-tem with a synchronous programming approach, see Appendix A, and that such anoperating system could satisfy current performance and expressivness criteria. Indeed,a synchronous program can be seen as an automata reacting to external stimuli, in thiscase the reconfiguration can take place between two reactions, where the system is ina stable state.
Also, we believe that we can enrich the proposed model by a formal proof (partiallyproposed as an extension of our work). In this way we could join two research areas
55
together: component-based systems and the process calculi in order to guarantee andproove properties of the operating system. Here it might be interesting to expressfailures in the formal system and implement, with dynamic reconfiguration, a faulttolerant operating system.
In the context of this work we made the hypothesis of a trusted environement. Theactual THINK framework doesn’t specify any protection mechanism against misbe-haved reconfiguration, instead all components run at the priviledged kernel level. Inthe future, some proposition concerning protection might be of interest.
In this work we considered only standalone operating systems. It would be interest-ing to propose and develop a global network infrastructure supporting the reconfigura-tion process. This area may be interesting for example for telecommunication systemsor mobile-phone access providers.
Optimization of the operating system is another area of interest when designing areconfigurable system. However, optimization may lead to non-reversible changes inthe system and the system might loose the reconfiguration capability. It would be inter-esting to design a reversible optimization mechanism, in order to improve performancewhile still allowing later reconfiguration.
56
Bibliography
[1] G. Berry. The esterel v5 language primer.
[2] G. Berry. Constructive semantics of esterel: From theory to practice (abstract).In Algebraic Methodology and Software Technology, page 225, 1996.
[3] G. Berry and Georges Gonthier. The esterel synchronous programming lan-guage: Design, semantics, implementation. Science of Computer Programming,19(2):87–152, 1992.
[4] B.N. Bershad, C. Chambers, S. Eggers, C. Maeda, D. McNamee, P. Pardyak,S. Savage, and E.G. Sirer. SPIN - an extensible microkernel for application-specific operating system services. SIGOPS Oper. Syst. Rev., 29(1):74–77, 1995.
[5] B.N. Bershad and P. Pardyak. Dynamic binding for an extensible system, Oct1996.
[6] B.N. Bershad and S. Savage. Issues in the design of an extensible operatingsystem, 1994.
[7] B.N. Bershad, S. Savage, P. Pardyak, E.G. Sirer, M. E. Fiuczynski, D. Becker,C. Chambers, and S. Eggers. Extensibility safety and performance in the SPINoperating system. In Proceedings of the fifteenth ACM symposium on Operatingsystems principles, pages 267–283. ACM Press, 1995.
[8] E. Bruneton, T. Coupaye, M. Leclerc, V. Quema, and J.-B. Stefani. An opencomponent model and its support in java. (to be published).
[9] E. Bruneton, T. Coupaye, and J. Stefani. Recursive and dynamic software com-position with sharing, 2002.
[10] E. Bruneton, T. Coupaye, and J.B. Stefani. The fractal component model.http://fractal.objectweb.org.
[11] M. Clarke and G. Coulson. An architecture for dynamically extensible operatingsystems, 1998.
[12] G. Denys, F. Piessens, and F. Matthijs. A survey of customizability in operatingsystems research. ACM Comput. Surv., 34(4):450–468, 2002.
57
[13] F. Duclos, J. Estublier, and R. Sanlaville. Separation of concerns and the extendedobject machine.
[14] D.R. Engler, M.F. Kaashoek, and J. O’Toole, Jr. Exokernel: an operating systemarchitecture for application-level resource management. In Proceedings of thefifteenth ACM symposium on Operating systems principles, pages 251–266. ACMPress, 1995.
[15] J.-F. Fassino. THINK : vers une architecture de systèmes flexibles. PhD thesis,École Nationale Supérieure des Télécommunications, December 11th, 2001.
[16] J.-F. Fassino, J. Stefani, J. Lawall, and G. Muller. Think: A software frameworkfor component-based operating system kernels, 2002.
[17] Fractal. http://fractal.objectweb.org.
[18] H. Haertig, M. Hohmuth, J. Liedtke, and S. Schoenberg. The performance ofmicrokernel-based systems. In Proceedings of the sixteenth ACM symposium onOperating systems principles, pages 66–77. ACM Press, 1997.
[19] N. Halbwachs. Synchronous programming of reactive systems. Kluwer AcademicPub., 1993.
[20] N. Halbwachs. Synchronous programming of reactive systems, a tutorial andcommented bibliography. In Tenth International Conference on Computer-AidedVerification, CAV’98, Vancouver (B.C.), June 1998. LNCS 1427, Springer Verlag.
[21] P.B. Hansen. The nucleus of a multiprogramming system. Commun. ACM,13(4):238–241, 1970.
[22] J. Helander and A. Forin. Mmlite: A highly componentized system architecture,1998.
[23] M. Horie, J. Pang, E. Manning, and G. Shoja. Using meta-interfaces to supportsecure, dynamic system reconfiguration. In Proceedings of the International Con-ference on Configurable Distributed Systems, page 164. IEEE Computer Society,1998.
[24] M. Horie, J.C. Pang, E.G. Manning, and G.C. Shoja. Designing meta-interfacesfor object-oriented operating systems. In Proc. 1997 IEEE Pacific Rim Conf.Communications, Computers, and Signal Processing, pages 989–992, Los Alami-tos, Calif., 1997. IEEE Press.
[25] J. Itoh, Y. Yokote, and R. Lea. Using meta-objects to support optimisation in theapertos operating system. In USENIX COOTS (Conference on Object-OrientedTechnologies, June 1995., pages 147–158 (or 147–157??), 1995.
[26] K42 Operating System, IBM. http://www.research.ibm.com/K42.
[27] K42/Tornado Operating System, University of Toronto.http://www.eecg.toronto.edu/ tornado/.
58
[28] A. Ketfi, N. Belkhatir, and P.-Y. Cunin. Dynamic updating of component-basedapplications.
[29] A. Ketfi, N. Belkhatir, and P.-Y. Cunin. Automatic adaptation of component-based software: Issues and experiences. In Proceedings of the InternationalConference on Parallel and Distributed Processing Techniques and Applications,pages 1365–1371. CSREA Press, 2002.
[30] L4ka publications. http://www.l4ka.org/publications.
[31] J. Liedtke. Improving ipc by kernel design. In Proceedings of the fourteenth ACMsymposium on Operating systems principles, pages 175–188. ACM Press, 1993.
[32] J. Liedtke. On micro-kernel construction. In Proceedings of the fifteenth ACMsymposium on Operating systems principles, pages 237–250. ACM Press, 1995.
[33] J. Liedtke. Toward real microkernels. Commun. ACM, 39(9):70–77, 1996.
[34] M.I. Seltzer, Y. Endo, C. Small, and K.A. Smith. Dealing with disaster: Survivingmisbehaved kernel extensions. In Proceedings of the 2nd Symposium on Opera-ting Systems Design and Implementation, pages 213–227, Seattle, Washington,1996.
[35] A. Senart. Canevas logiciel pour la construction d’infrastructures logicielle dy-namiquement adaptables. PhD thesis, Institut National Polytechnique de Greno-ble, 2003.
[36] C. Small. Misfit: A tool for constructing safe extensible c++ systems, 1997.
[37] C. Small and M. Seltzer. Structuring the kernel as a toolkit of extensible, reusablecomponents, 1995.
[38] C. A. N. Soules, J. Appavoo, K. Hui, R. W. Wisniewski, D. Da Silva, G. R.Ganger, O. Krieger, M. Stumm, M. Auslander, M. Ostrowski, B. Rosenburg, andJ. Xenidis. System support for online reconfiguration. In Proceedings of Usenix2003, pages 141–154, 2003.
[39] J. Stankovic, L.F. Friedrich, M. Humphrey, M. Marley, and J. Haskins. A surveyof configurable, component-based operating systems for embedded applications.IEEE Micro, 21(3):54–68, 2001.
[40] R. Wahbe, S. Lucco, T.E. Anderson, and S.L. Graham. Efficient software-basedfault isolation. ACM SIGOPS Operating Systems Review, 27(5):203–216, De-cember 1993.
[41] W. Wulf, E. Cohen, W. Corwin, A. Jones, R. Levin, C. Pierson, and F. Pol-lack. Hydra: the kernel of a multiprocessor operating system. Commun. ACM,17(6):337–345, 1974.
[42] Y. Yokote. The apertos reflective operating system: the concept and its imple-mentation. In conference proceedings on Object-oriented programming systems,languages, and applications, pages 414–434. ACM Press, 1992.
59
Appendix A
Synchronous programming,reactive systems
Computer systems can be divided into three broad categories (G.Berry in [3] andN.Halbwachs in [20]) :
Transformational systems that compute an output from the initial input values andthen they terminate. An example of such a system is a compiler or a numerical program.
Interactive systems interact with their environment, but at their own speed. Thesystem delivers the services (on behalf of a user request), when they are available.Classical operating systems fall into this category, as well as the Internet for example.(see determinism for more)
Reactive systems maintain a permanent interaction with their environment and con-tinuously react to inputs from the environment by sending outputs to it. Reactive sys-tems are event-driven (or input-driven). Most embedded systems and real-time systemsare reactive systems.
Characteristics of reactive systems
Determinism A system is deterministic, if, presented with the same input, it alwaysproduces the same output sequence, otherwise it is non-deterministic. A system’s re-action is uniquely determined by the kind and the timing of the external stimuli. Adeterministic behaviour is time measurable and non-trivial correctness proofs can beperfomed. For example temporal-logic formula checkers can be applied if the reactivesystem is described with deterministic automata.
Concurrency Several concurrent components are used to describe and to realize thebehaviour.
Real-time Most of reactive systems are suposed to meet strict constraints with re-gard to timing.
60
Synchronous paradigm, Synchrony
Eventhough many techniques are available to describe and implement reactive sys-tems, they force a tradeoff between determinism and concurrency as they implementconcurrency on an asynchronous model, where processes compete in a non-deterministicway for resources, resulting in some problems when programming and reasonningabout reactive systems (programs) (G. Berry in [3]). Reactions can compete witcheach other, they are not atomic (neither supported by the language nor by the systemand difficult to do it by hand). Time accuracy for time-critical applications may not beaccurate, or different subprocesses may have different perception of the system withina single reaction. For example a counter may be read twice within a reaction, deliveringtwice a different value.
These problems are solved with the synchrony paradigm. Synchrony conceptuallymeans that the reaction takes no time and that outputs are available instantaneously asinputs, the reaction is atomic with regard to other reactions and to the underlying envi-ronment. Synchrony reconcilies determinism and concurrency and simplifies controllerprogramming.
Several languages exist to write synchronous programs (synchrony hypothesis),yet their style may differ slightly. For example Esterel is an imperative language andLustre is a declarative data-flow language (see N.Halbwachs [20] for more details).Synchronous programs can be compiled into efficient automatas, delivering run-timeefficiency and predictability. They are also more rigorous and easier to reason about,for example with an automata verification system.
The issues in synchronous programming are out of the scope of this work. Theseissues include topics, such as causality analysis, compilation into a deterministic au-tomata, the proof of correctness and many more.
Synchronous approach for building operating systems
Because of the event-driven nature of operating systems, we could apply the syn-chronous paradigm to build an operating system. In this way we could extend the for-mal proof to the whole operating system and. With synchronous kernel (or operatingsystem) we mean an operating system built with synchronous programming.
The figure A.1 shows a possible construction of a synchronous operating systemkernel. Yet some basic mechanisms are needed, such as interrupt handlers and thereactive engine, responsible for collecting events occured in an "epoch" and triggeringthe reaction.
At the time of this writing, none of the research projects known are pursuing thisconcept. Our Proposition II (4.2.2) is a first step toward a synchronous THINK kernel.It would be interesting to build an asynchronous system on top of a synchronous kernel,this issue will be probably explored in subsequent research at France Telecom R&D.
In the case of a synchronous kernel it would be relatively easy to reconfigure thesystem, because the system is in a stable state after every reaction termination. Insteadof triggering a new reaction, the reactive engine could reconfigure safely the system.Here only a state transfer mechanism would be needed. A language for addressing ornaming parts of the system could be necessary and in general, even more sophisticated
61
Figure A.1: Construction of a synchronous operating system kernel.
verifications could be done (this is the goal), but again, these considerations are out ofthe scope of this work.
62
Appendix B
HelloWorld in Think
Figure B.1: Helloworld in THINK
B.1 ADL
primitive helloworld {provides activity.api.Main as mainrequires video.api.Console as consskeleton hwBase_code.c
}
composite hwKernel implements activity.api.Main {contains console = powerpc.macintosh.video.lib.screencontains hw = helloworldbinds this (activity.api.Main) to hw.mainbinds hw.cons to console (video.api.Console)controller org.objectweb.think.controller.Static
}
63
B.2 Components and their implementation
#include <activity/api/Main.idl.h>#include <video/api/Console.idl.h>
#include <fractal/api/componentskeleton.h>#include <kortex.h>
struct helloworld_codedata {// Imported interfacesRvideo_api_Console *console;int position;
};
extern void mainentry(void* _this);static struct Mactivity_api_Main _main = {
main: mainentry,};
/********************************/static void mainentry(void* _this){
struct helloworld_codedata *self =(struct helloworld_codedata *)_this;
CALL3(self->console, putxycs,self->position, self->position,"Hello World !");
while(1); // end-loop}
64
Appendix C
Simple syntax of the systemdescription
C.1 System description
A system configuration is described as a set of controllers and components, in-terfaces they provide and their respective bindings. Encapsulate in order to performverifications on state transfer, we could also describe the data encapsulated in compo-nents.
A controller encapsulates components, that provide some interfaces. However im-plicitly these interfaces are only visible within the controller and not outside. If acontroller provides an interface of its sub-component we must explicit this fact. We in-troduce the symbol ν, interface names proceeded by ν are visible outside the controller.Visibility defines also the scope of an interface.
As already stated, a reconfiguration may require state transfer between compo-nents. A component designer may decide the internal component state to be the set ofattributes exposed by the component. In our formalism we provide means to describecomponent’s attributes. With means of this description we can express how attributesfrom an old component are mapped to attributes of the new component and eventuallyreject the reconfiguration if attributes mismatch. However this description is optional,see the implementation (State transfer 4.2.1) for more detailed argumentation.
The next section proposes a simple syntax of a system configuration description.In this proposition, component’s attributes are not considered.
65
C.2 Syntax
system-description := [alias-definitions] component-definition ";"
alias-definitions := alias-definition [";" alias-definitions]alias-definition := alias-component | alias-interfacealias-interface := alias-name "=" interface-type
alias-component := alias-name "=" component-definition
component-definitions := component-definition ["|" component-definitions]component-definition := [provided] component-symbol "[" component-contents "]" [required]
| aliasprovided := visibility [provided];visibility := νattribute-symbol | νinterface-symbolrequired := interface-type [required]
component-contents := [interface-definitions] ";" [component-definitions] ";" [bindings]
interface-definitions := interface-definition ["|" interface-definitions]interface-definition := interface-symbol "<" interface-type ">"
inteface-type := interface-signature| alias
interface-signature := proc-signature ["|" interface-signature]proc-signature := return-value-type "(" arg-types ")"
arg-types := [arg-symbol ":"] arg-type ["," arg-types]
bindings := "(" comp-itf "," comp-itf ")" ["," bindings]comp-itf := component-symbol"<"interface-symbol">"
| this"<"interface-symbol">"
C.3 Reconfiguration rules
The table C.3 present an example of a transformation (or reconfiguration) rule.Each rule corresponds to a particular action that has to be taken in the system.
alias[component-contents]→ alias’[component-contents](the component alias replaced by alias’ of the same type)
Table C.1: Reconfiguration rules, example.
66
