Motivation

Betriebssystemtechnik



Operating System Engineering (OSE)

Bisher betrachtete Konzepte stammen aus der Welt der Softwaretechnik ...  Produktlinienentwicklungsprozess  Merkmalmodelle



Anpassbare Betriebssysteme in der Forschung

... und aus der Welt der Programmiersprachen.  Präprozessoren (z.B. Frame Prozessoren)  Aspektorientierte Programmierung  Objektorientierte Programmierung  Generative Programmierung



1

Welche Lösungen sind in der Betriebssystemforschungsgemeinde eingesetzt bzw. entwickelt worden? 2

© 2005 Olaf Spinczyk

Variantenvielfalt

Ausgangspunkt für Forschung (1) 

... ist der „Stand der Kunst“:

adaptierbares Betriebssystem

Einheiten

Bindung

statisch konfigurierbar

dynamisch rekonfigurierbar

manuell

adaptierbares Betriebssystem

Module

Policies

Einheiten

Bindung

untrusted

statisch konfigurierbar

dynamisch rekonfigurierbar

manuell

automatisch



Module

Policies

untrusted

automatisch

Großrechner, Workstation und PC Betriebssysteme:  dynamisches Laden und Entladen von Modulen wie Treibern oder

Dateisystemen, teils automatisch, teils auch statisch konfiguriert © 2005 Olaf Spinczyk

3

© 2005 Olaf Spinczyk

4

Im Zentrum der BS- Forschung [1]

Ausgangspunkt für Forschung (2) 

... ist der „Stand der Kunst“:

... ist, was neu und herausfordernd ist: adaptierbares Betriebssystem

adaptierbares Betriebssystem

Einheiten



Policies

untrusted

statisch konfigurierbar

manuell

automatisch

Eingebettete- und Echtzeit- Betriebssysteme:



 statische Konfigurierung auf Modulebene und gut modularisierte



Strategien (z.B. Scheduling), i.d.R. keine Dynamik © 2005 Olaf Spinczyk

Problem: nicht vertrauenswürdige Module können einen Systemkern zum Absturz bringen oder lahm legen



Ausführung von nicht vertrauenswürdigem Code Adaptierbarkeit von Policies (Systemstrategien) 6

Idee: Verkleinerung der „Trusted Computing Base“ und Schutz durch Isolation Benutzermodus

Benutzer Dateisystem

Privilegierter Modus

Lösungsansatz: Schutz

Interprozesskomm.

Benutzermodus

E/A und Geräteverwaltung

 durch Isolation

...

Virtueller Speicher

- „Sandboxing“  durch sichere Sprachen - Modula 3, wie z.B. in SPIN - Java, wie z.B. in JX

Prozessverwaltung Hardware



Lösungsansatz: Überprüfung 

 der Quelle (z.B. Systemadministrator, BS- Hersteller)  des Verhaltens („Proof Carrying Code“)

© 2005 Olaf Spinczyk

automatisch

Meilenstein 2: Mikrokerne (1)

 exzessiver Ressourcenverbrauch



untrusted

© 2005 Olaf Spinczyk

 unkontrollierte Speicherzugriffe 

Policies

 vor allem dynamisch und im Hinblick auf Performance 5

Meilenstein 1: Erweiterbare Kerne 

Module

dynamisch rekonfigurierbar

7

Privilegierter Modus

Virtueller Speicher

manuell

Module

Dateiserver

dynamisch rekonfigurierbar

Prozessserver

statisch konfigurierbar

Einheiten

Bindung

Gerätetreiber

Bindung

Benutzer



Mikrokern Hardware

die Aufgabe des Mikrokerns beschränkt im Wesentlichen auf die Realisierung des Nachrichtenaustauschs das Konzept sorgt für vergleichsweise einfache (dynamische) Rekonfigurierbarkeit © 2005 Olaf Spinczyk

8

Zwischenfazit

Meilenstein 2: Mikrokerne (2) 

Beispiel: der externe Pager von Mach

Anwendung Seitenfehler



die klassische Betriebssystemforschung befasste sich hinsichtlich Adaption viele Jahre lang stark mit der dynamischen Erweiterung und Rekonfigurierung unter dem Blickwinkel Performance und Sicherheit



heute hat sich die Situation verändert

Pager

Wiederaufnahme

Aufrufe zur Adressraumverwaltung

 keine eingebetteten Systeme und statische Konfigurierung  Zahlen von David Tennenhouse

Mikrokern

 Rob Pikes „System Software Research is Irrelevant“  ... und vor allem neue Anwendungsbereiche



Nutzen: anwendungsspezifische Paging Strategien können die Performance erheblich steigern



Problem: viele Kontextwechsel wirken negativ auf die Performance © 2005 Olaf Spinczyk

- Ubiquituous- und Pervasive Computing - Sensor Networks 

9

© 2005 Olaf Spinczyk

Konfigurierbare Forschungssysteme 

R. Campbell, 1987 University of University of Illinois at Urbana- Champaign



in C++ mit einigen Erweiterung implementiert

Choices, 1987  eines der ersten objektorientierten Betriebssysteme



OSKit, 1997

 Garbage Collection

 Bibliothekssystem, nur schnell dank „Knit“ 

 Klassenobjekte und Laufzeittypprüfungen

TinyOS, 2000

 dynamisches Nachladen von Subklassen

 Minimales BS für Sensornetzwerke, NesC Programmiersprache 



PURE, 1995- 2003

setzt konsequent den Framework Gedanken um  anwendungsspezifische Erweiterung und Spezialisierung

 Merkmalmodell, Aspekte, Minimierung der Größe 

10

Choices [2, 3]

... einige (bedeutende) Systeme als Beispiel: 

Themen im Bereich der Spezialzwecksysteme und statische Konfigurierung werden inzwischen ernst(er) genommen

vorhandener Framework Klassenhierarchien

EPOS, 1999

 Instanziierung der gewünschten Klassen und Verknüpfung der

passenden Objekte

 Metaprogrammierung, automatische Anwendungsanalyse

 Hierarchien und einheitliche (abstrakte) Schnittstellen © 2005 Olaf Spinczyk

11

© 2005 Olaf Spinczyk

12

Choices - Fazit

Choices – ein Beispielsubsystem 

die Choices Dateisystem Hierarchie:



MSDOSEntry MemoryObject

MultimaxDisk UNIXInode

 erweiterbar  anwendungsspezifisch spezialisierbar

BSDInode SystemVInode



ValidatingMemoryObject ObjectContainer

MultimaxContainer UNIXContainer

BSDContainer SystemVContainer



ObjectDirectory



MSDOSDirectory SystemVDirectory

Warum gibt es heute nicht mehr objektorientierte Betriebssysteme?  der Ressourcenverbrauch spielt bei der Auswahl der Methoden im

ValidatingDirectory

© 2005 Olaf Spinczyk

Einsatzgebiet sind hauptsächlich parallele Systeme, z.B.  Intel Hypercube  NS 32332

BSDDirectory HashedBSDDirectory

die Entwickler haben den Overhead durch dynamisches Binden in Kauf genommen  Laufzeiten (vor allem Kommunikation) werden als gut angesehen  Größen werden nicht publiziert

MSDOSContainer Object

Choices ist ein als objektorientiertes Framework aufgebautes System

BS- Bereich eine enorme Rolle 13

© 2005 Olaf Spinczyk

OSKit [4]

14

OSKit – Trennbare Module



University of Utah





Ziel: Schaffung einer Basisplattform für BS- Forschung  eine Sammlung von Bibliotheken

alle OSKit Module sollen auch einzeln verwendbar sein  Aufrufe über Modulgrenzen werden daher mit einer Indirektionsstufe

versehen 

überschreibbare Funktionen (1. Ansatz)  Speicheranforderungen in Gerätetreibern erfolgen immer mit

fdev_mem_alloc. Der OSKit Speicher- Manager stellt diese Funktion bereit. Der Benutzercode kann sie aber auch selbst bereitstellen. 

dynamisches Binden (2. Ansatz)  eine COM Schnittstelle wird beispielsweise beim Zugriff auf

Blockgeräte verwendet  Dateisysteme erwarten ein kompatibles Blockgerät als Parameter,

das auch vom Benutzercode stammen kann. 

die Indirektion macht die Komponentenübergänge teuer  Komponenten werden eher grobgranular ausgelegt

© 2005 Olaf Spinczyk

15

© 2005 Olaf Spinczyk

16

OSKit – Knit (2)

OSKit – Knit (1) [5] 

Knit ergänzt C um ein Komponentenmodell und verknüpft Komponten mittels Codetransformation oder ObjektcodeManipulation



weitere Aufgaben von Knit  Generierung von Modul- Initialisierungscode unter Berücksichtung

von Reihenfolgeabhängigkeiten  Verarbeitung beliebiger Properties und Constraints  Umbenennungen

importierte Symbole serve_cgi serve_cgi

fopen...

 Verschmelzen von C Implementierungsdateien zwecks Inlining

serve_file

serve_cgi

int serve_web(...) { if (...) serve_cgi(...); else serve_file(...); }

serve_file serve_unlocked fopen..

...



...

serve_web

serve_logged

exportierte Symbole

 fetch stall cycles: 781 - > 455

compound unit

© 2005 Olaf Spinczyk

 text size: 109464 - > 106065

17

© 2005 Olaf Spinczyk

OSKit – Fazit 



OSKIT ist eine Sammlung von Komponenten



ein besonderes Problem sind Importe  Indirektion durch den Binder  Indirektion durch Funktionszeiger (z.B. COM Schnittstelle)





D. Culler, 2000 University of California, Berkeley Zieldomäne: drahtlose SensorNetzwerke eine typische Hardware:

 Indirektionen sind teuer!

 4Mhz, 8bit MCU (ATMEL)

Knit schafft Abhilfe

- 512 bytes RAM, 8K ROM  900Mhz Radio (RF Monolithics)

 C wird um ein Komponentenmodell und eine domänenspezifische

Sprache (DSL) zur Komponentenbeschreibung ergänzt Vermelzen von Implementierungsdateien und Inlining erreichen

Connectivity

 LED outputs

ressourcensparende Systeme sollten daher ...

 Serial Port

 keine (binären) Komponentenmodelle verwenden



 mit Inlining von Funktionen arbeiten © 2005 Olaf Spinczyk

Routing Tree Link

- 10- 100 ft. range  Temperature Sensor & Light Sensor

 den entscheidenden Performance- Vorteil konnte Knit durch das 

18

TinyOS [6]

 ein Konzept, das von C und typischen Bindern nicht unterstützt wird 

der Gewinn durch den Einsatz von Knit ist beachtlich: (eine modulare Router Implementierung [Pentium Pro])  cycles: 2411 - > 1574

serve_web

serve_web

atomic unit

serve_file

19

trotz Größenminimierung setzt TinyOS auf Komponenten! © 2005 Olaf Spinczyk

20

TinyOS – Komponentenmodell (1)

TinyOS – Komponentenmodell (1) 



TinyOS Komponenten haben wie Knit Komponten Importe und Exporte. Commands

Event

StdControl Timer TimerM Clock

module TimerM { provides { interface StdControl; interface Timer[uint8_t id]; } uses interface Clock; } implementation { ... im C Dialekt NesC }

interface TinyOS Komponenten habenStdControl wie Knit{ Komponten command result_t init(); Importe und Exporte. command result_t start();

Commands

command result_t stop(); module TimerM { provides { interface StdControl; interface Timer { interface Timer[uint8_t command result_t start(char type, id]; } uint32_t interval); uses interface command result_t stop();Clock; } event result_t fired(); implementation { } ... im C Dialekt NesC interface} Clock { }

Event

StdControl Timer TimerM Clock

command result_t setRate(char interval,

 





Commands sind synchrone Funktionsaufrufe Events signalisieren asynchron das Auftreten eines Ereignisses Komponenten implementieren einen Zustandsautomaten





21

© 2005 Olaf Spinczyk

© 2005 Olaf Spinczyk

TinyOS – Komponentenmodell (2) 

char scale); Commands sind synchrone Funktionsaufrufe event result_t fire(); } Events signalisieren asynchron das Auftreten eines Ereignisses Komponenten implementieren einen Zustandsautomaten

22

TinyOS – NesC [7] 

TinyOS Komponenten können auch hierarchisch verbunden werden

das Besondere ist die Implementierung in NesC  unterstützt direkt das Komponentenmodell von TinyOS  kein dynamischer Speicher

StdControl Timer

StdControl Timer TimerM Clock

Clock HWClock

 keine Aufrufe über Funktionszeiger

configuration Timer C { provides { interface StdControl; interface Timer; } } implementation { components TimerM, HWClock; StdControl = TimerM.StdControl; Timer = TimerM.Timer; TimerM.Clock -> HWClock.Clock; }

 alle Komponenten werden bei der Übersetzung gemeinsam

betrachtet 

 Eliminierung von unbenutzem Code  Optimierung des Inlinings  automatische Erkennung potentieller Race Conditions App

Code size Code Data size CPU inlined non-inlined reduction reduction surge 14794 16984 12% 1188 15% Mate 25040 27458 9% 1710 34% TinyDB 64910 71724 10% 2894 30%

TimerC

© 2005 Olaf Spinczyk

Ergebnis: Whole Program Analysis and Optimization

23

© 2005 Olaf Spinczyk

24

PURE

TinyOS – Fazit 



TinyOS geht mit der Optimierung noch weiter als OSKit mit Knit



W. Schröder- Preikschat, 1995- 2003 Universität Potsdam und Magdeburg

 Whole Program Optimization



Zieldomäne: kleinste eingebettete Systeme

damit dies möglich ist, müssen die Komponenten aber in der Programmiersprache NesC implementiert sein

 hochgradige Konfigurierbarkeit 

Ansatz: familienbasierter Entwurfs



Umfang: ca. 900 Dateien, 300 Klassen Herausforderungen:

 Parnas u. Habermann, Vererbung (C++) 

 Beherrschung der Konfigurationsvielfalt  Umsetzung im Programmcode

© 2005 Olaf Spinczyk

25

© 2005 Olaf Spinczyk

PURE – die Thread- Hierarchie 

... extrem feingranular aufgebaut: 13 Ebenen!



unterstützt z.B. diverse Scheduling- Strategien



PURE - Konfigurierung 

Problem: je feiner die Granularität der konfigurierbaren Einheiten wird, desto unüberschaubarer ist das System für den Anwender (=Systemkonfigurator).  Wie sind bei PURE Klassenaliase zu konfigurieren, um eine

gewünschte Wirkung zu erzielen?

Klassenaliase konfigurieren die Schichten

 Nach welchen Regeln werden z.B. Komponenten bei TinyOS und

Knit verbunden? Nicht nur eine Frage der Schnittstellen!

 anfangs über Präprozessor-



Konfigurationsflags  durch leere (aber kompatible) Klassen wie Deafmute oder Stoic können Schichten auch inaktiv sein

© 2005 Olaf Spinczyk

26

Benötigt wird ein Modell und eine „Werkbank“.  das Modell wurde übernommen: Merkmalmodelle  die Werkbank wurde selbst gemacht: Consulat, jetzt pure::variants

27

© 2005 Olaf Spinczyk

28

PURE – Aspekte (2)

PURE – Aspekte (1) 

Problem: quer schneidende Belange  redundanter, schwer zu wartender Code  schwer wegzulassen  Verbindungspunkte nicht konfigurierbar



Beispiel: Unterbrechungssynchronisation  ... beim Eintritt in den Kern  166 Punkte in 15 Klassen



Benötigt wird ein Modell und eine „Werkzeug“.  das Modell wurde übernommen: AOP  das Werkzeug wurde selbst gemacht: AspectC++

29

© 2005 Olaf Spinczyk

© 2005 Olaf Spinczyk

PURE - Größen 

30

PURE - Fazit 

... durchaus mit denen von TinyOS vergleichbar  Inlining dank C++ und Inline Optimierungswerkzeug

Feingranular konfigurierbare Systeme werden schnell unüberschaubar

 kaum virtuelle Funktionen durch den familien- basierten Entwurf

 Welche Komponenten passen zusammen?  Was bedeuten sie für das Gesamtverhalten?

preemptive 4062

preemption

non- preemptive 1699

coordinative 2306 dispatching

objectification

© 2005 Olaf Spinczyk

interruptive 1268

 Komponenten mit Schnittstellen  noch ein Schritt höher: abstrakte Merkmale

propagation

synchronization

Der Weg auf eine höhere Abstraktionsebene muss beschritten werden  Klassen mit Methoden

scheduling

cooperative 1648 exclusive 434





Aspekte lösen viele Probleme bei der Umsetzung von Variabilitäten im Programmcode



PURE hat ca. 250 Merkmale und 300 C++ Klassen

interruption

31

© 2005 Olaf Spinczyk

32

EPOS - Systemabstraktionen

EPOS [8] 

A. Fröhlich, 1999 GMD FIRST Berlin



Zieldomäne: eingebettete und parallele Anwendungen



Ansatz: Application- Oriented System Design



„application ready“



unabhängig vom Ausführungsszenario



Beispiel:

 Szenario- unabhängige Systemabstraktion

System Abstraction

 ein Faden mit einem bestimmten

 Szenarioadapter

Scheduling Verhalten

 Inflated Interfaces

 KEIN Faden für eine Einprozessor-

 statische Anwendungsanalyse

oder Multi- Tasking Umgebung

 statische Template- Metaprogrammierung

system micro- components

© 2005 Olaf Spinczyk

33

© 2005 Olaf Spinczyk

EPOS - Szenarioadapter 

passt eine Systemabstraktion an eine bestimmte Ausführungsumgebung an.



sorgt auch für die Anpassung der Mikro- Komponenten in den Systemabstraktionen



Beispiele:

34

EPOS – Anforderungsanalyse (1) 

die Anwendungen werden gegen Inflated Interfaces programmiert  wohl bekannt

Scenario Adapters

 leicht verständlich 



nicht alle Systemvarianten haben eine Implementierung für die gesamte Schnittstelle Anhand ...  der verwendeten Schnittstellen,  der referenzierten Funktionen und  der Art der Referenzierung

 ein SMP Adapter  ein RPC Adapter



kann auf die geeignetste Systemkonfiguration geschlossen werden  statische Anwendungsanalyse

© 2005 Olaf Spinczyk

35

© 2005 Olaf Spinczyk

36

EPOS – Anforderungsanalyse (3)

EPOS – Anforderungsanalyse (2) complex application program code = new Segment(buffer, size); task = new Task(code, data); thread = new Thread(task, &entry_func, priority, SUSPENDED, arguments); mutex- >entry(); Mailbox mailbox; mailbox >> message; File file(name); file