sus-03.7: betriebssysteme und kontext · modul, so dass später dynamisch advice-code angebunden...
TRANSCRIPT
Software ubiquitärer Systeme (SuS)
Betriebssysteme und Kontext
https://ess.cs.tu-dortmund.de/DE/Teaching/SS2016/SuS/
Horst Schirmeier, Olaf Spinczyk
[email protected]://ess.cs.tu-dortmund.de/~hsc
AG Eingebettete SystemsoftwareInformatik 12, TU Dortmund
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 2
Motivation● Einschränkungen ubiquitärer Systeme: CPU, RAM, Energie,
Konnektivität mit (Funk-)Netzen, …● Bei kleinsten Geräten kann man den Einschränkungen mit
extremer Spezialisierung begegnen.– feingranulare Maßschneiderung der Software zur Übersetzungszeit– Auswahl der günstigsten/kleinstmöglich dimensionierten/etc.
Hardware– Beispiele: Smart Dust, RFID, …
● Bei größeren Geräten mit mehreren Funktionalitäten reicht die statische Konfigurierung möglicherweise nicht aus!– Betrachten wir folgendes Szenario …
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 3
Der Alltagsbegleiter● Beispiel: „Alltagsbegleiter“ PDA/Smartphone
– temporär unterschiedliche Dateisysteme (Speicherkarten)
– MP3s für unterwegs– sicherheitsrelevante Daten
Hardware
BS-Kern
Anwendungen
DisplayKeypadWLAN
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 4
Der Alltagsbegleiter● Beispiel: „Alltagsbegleiter“ PDA/Smartphone● Kontext 1: eingesteckte Speicherkarte, FAT32-
Dateisystem– dynamisches Nachladen des FAT32- und des SD-Karten-
Treibers– Einschalten des SD-Kartenlese-Geräts
Hardware
FAT32
BS-Kern
Anwendungen
SDDisplayKeypadWLAN
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 5
Der Alltagsbegleiter● Beispiel: „Alltagsbegleiter“ PDA/Smartphone● Kontext 1: eingesteckte Speicherkarte, FAT32-
Dateisystem● Kontext 2: Benutzer hört unterwegs MP3s
– Soundtreiber wird nachgeladen, Device eingeschaltet– WLAN-/FAT32-/SD-Treiber werden nicht mehr benötigt
Hardware
Sound
BS-Kern
Anwendungen
DisplayKeypad
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 6
Der Alltagsbegleiter● Beispiel: „Alltagsbegleiter“ PDA/Smartphone● Kontext 1: eingesteckte Speicherkarte, FAT32-
Dateisystem● Kontext 2: Benutzer hört unterwegs MP3s● Kontext 3: Wechsel in ein „unsicheres“ WLAN
– Kernel wird temporär um Sicherheits-Checks erweitert– langsamer, ressourcenintensiver, aber nur in „unsicheren“
Umgebungen!
Hardware
BS-Kern
Anwendungen
DisplayKeypadWLAN
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 7
Der Alltagsbegleiter● Beispiel: „Alltagsbegleiter“ PDA/Smartphone● Kontext 1: eingesteckte Speicherkarte, FAT32-
Dateisystem● Kontext 2: Benutzer hört unterwegs MP3s● Kontext 3: Wechsel in ein „unsicheres“ WLAN
– Kernel wird temporär um Sicherheits-Checks erweitert– langsamer, ressourcenintensiver, aber nur in „unsicheren“
Umgebungen!
● Je nach Kontext ein dynamisch angepasstes (Betriebs-)System– mit großem Einsparpotential (Strom, RAM, CPU)!– aber: Mit welchen Techniken ist das realisierbar?– Was kostet das (im Hintergrundspeicher, zur Lade-/Laufzeit)?
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 8
Inhalt● Kontextabhängigkeit
– … auf Betriebssystem-Ebene?
● Varianten der Adaptierbarkeit– Adaptierbare vs. adaptive Systeme– „Große“ vs. eingebettete und Echtzeit-BS
● Dynamische Anpassung– Techniken– Betriebssysteme
● Zusammenfassung
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 9
Inhalt● Kontextabhängigkeit
– … auf Betriebssystem-Ebene?
● Varianten der Adaptierbarkeit– Adaptierbare vs. adaptive Systeme– „Große“ vs. eingebettete und Echtzeit-BS
● Dynamische Anpassung– Techniken– Betriebssysteme
● Zusammenfassung
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 10
Kontextabhängigkeit(context awareness)
● Ziel:– Computer sollen genug Wissen über die aktuelle Situation des Nutzers
ansammeln können, um zu jeder Zeit nützliche Dienste und Informationen bereitzustellen sowie Ressourcen zu sparen.
● Kontext-gewahres Verhalten erfordert …– Erfassung
● mittels Sensoren, Kommunikation oder Nutzerinteraktion– Repräsentation der Welt im ubiquitären Rechnersystem, z.B.
● Position, z.B. GPS oder Raumnummer● Rolle des aktuellen Benutzers● In der Nähe befindliche Geräte● Sensordaten, z.B. Temperatur, Windgeschwindigkeit, …
– Reaktion auf Veränderungen
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 11
... auf Betriebssystem-Ebene?● Beispiel: Handy mit
Navigations-Anwendung● Positionsbestimmung per
GPS– stromhungrig!
● Repräsentation:– GPS-Koordinaten, klassifiziert nach
„innerhalb“ / „außerhalb von Großstadt“
● Kontext wechselt zu „Großstadt“– WLAN-Modul ein-, GPS-Modul ausschalten
– Koordinatenbestimmung anhand WLAN-Datenbank
Kontext
erfassen
reagieren
repräsentieren
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 12
... auf Betriebssystem-Ebene?● Beispiel: PDA mit sicher-
heitsrelevanten Daten● Kontext: SSID des WLAN,
in das eingebucht ist
● Repräsentation:– SSID, klassifiziert nach „sicheres“ und
„unsicheres“ Netz
● Kontext wechselt zu „unsicher“– Kernel wird um Sicherheits-Checks
erweitert– langsamer, ressourcenintensiver, aber
nur in „unsicheren“ Umgebungen!
Kontext
erfassen
reagieren
repräsentieren
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 13
Inhalt● Kontextabhängigkeit
– … auf Betriebssystem-Ebene?
● Varianten der Adaptierbarkeit– Adaptierbare vs. adaptive Systeme– „Große“ vs. eingebettete und Echtzeit-BS
● Dynamische Anpassung– Techniken– Betriebssysteme
● Zusammenfassung
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 14
Varianten der Adaptierbarkeit von BS
● adaptierbare Systeme können durch externe Eingriffe (statisch oder dynamisch) an veränderte Bedingungen angepasst werden
● adaptive Systeme können sich selbständig an veränderte Bedingungen anpassen → Selbstorganisation, Reflektion/Introspektion
adaptierbaresBetriebssystem
Bindung Einheiten
statischkonfigurierbar
dynamischrekonfigurierbar
manuell automatisch
Module Policies untrusted
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 15
Ausgangspunkt für Forschung (1)
● Großrechner-, Workstation- und PC-Betriebssysteme:– dynamisches Laden und Entladen von Modulen wie Treibern oder
Dateisystemen, teils automatisch, teils auch statisch konfiguriert
● … ist der „Stand der Kunst“:adaptierbares
Betriebssystem
Bindung Einheiten
statischkonfigurierbar
statischkonfigurierbar
dynamischrekonfigurierbar
dynamischrekonfigurierbar
manuellmanuell automatischautomatisch
ModuleModule Policies untrusted
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 16
Ausgangspunkt für Forschung (2)● … ist der „Stand der Kunst“:
● Eingebettete- und Echtzeit-Betriebssysteme:– statische Konfigurierung auf Modulebene und gut modularisierte
Strategien (z.B. Scheduling), i.d.R. keine Dynamik
adaptierbaresBetriebssystem
Bindung Einheiten
statischkonfigurierbar
dynamischrekonfigurierbar
manuell automatisch
Module Policies untrusted
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 17
Im Zentrum der BS-Forschung [1]
● Ausführung von nicht vertrauenswürdigem Code● Adaptierbarkeit von Policies (Systemstrategien)
– vor allem dynamisch und im Hinblick auf Performance
● … ist, was neu und herausfordernd ist:adaptierbares
Betriebssystem
Bindung Einheiten
statischkonfigurierbar
statischkonfigurierbar
dynamischrekonfigurierbar
dynamischrekonfigurierbar
manuellmanuell automatischautomatisch
ModuleModule Policies untrusted
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 18
Inhalt● Kontextabhängigkeit
– … auf Betriebssystem-Ebene?
● Varianten der Adaptierbarkeit– Adaptierbare vs. adaptive Systeme– „Große“ vs. eingebettete und Echtzeit-BS
● Dynamische Anpassung– Techniken– Betriebssysteme
● Zusammenfassung
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 19
Adaptierbare/adaptive Systeme● teils nur adaptierbar, teils adaptiv● auf Anwendungsebene
– Infrastruktur zum dynamischen Laden und Linken notwendig!
● aber auch auf Betriebssystem-Ebene– verschiedene Granularitäten (Module, Policies)– und Problemstellungen
(untrusted code, Effizienz zurLaufzeit, Hochverfügbarkeit, …)
adaptierbaresBetriebssystem
Bindung Einheiten
statischkonfigurierbar
dynamischrekonfigurierbar
manuell automatisch
Module Policies untrusted
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 20
Inhalt● Kontextabhängigkeit
– … auf Betriebssystem-Ebene?
● Varianten der Adaptierbarkeit– Adaptierbare vs. adaptive Systeme– „Große“ vs. eingebettete und Echtzeit-BS
● Dynamische Anpassung– Techniken– Betriebssysteme
● Zusammenfassung
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 21
Techniken: dynamisches Binden● genauer: dynamisches Laden und Binden
– dynamisch gelinkte Bibliotheken lassen sich leichter aktualisieren– Funktionalität kann zur Laufzeit nachgeladen und auch wieder
entladen werden● UNIX-Standard-Format für dynamische Bibliotheken: ELF
– Executable and Linking Format– können an beliebige Stellen geladen werden, enthalten daher Position
Independent Code (PIC)→ Textsegment muss nicht reloziert werden
– Global Offset Table (GOT) für Offsets der globalen Variablen– Procedure Linkage Table (PLT) für Offsets der Funktionen
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 22
ELF mit GOT und PLTProgramm Bibliothek
Data
Text
PLT
GOT
libx_foo()
Data
Text
PLT
GOT
errno
lazy binding
● Indirektionen, Lade- und Laufzeitoverhead
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 23
Techniken: dynamisches Binden● expliziter Aufruf des dynamischen ELF-Linkers
– z.B. zum Nachladen von Plugins zur Laufzeit
– dlopen() zum Laden
– dlsym() zum Auflösen eines Symbols
– Dasselbe passiert implizit, wenn eine Bibliothek beim Programmstart geladen wird!
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 24
Techniken: dynamisches Binden● Nachteile:
– Infrastruktur: Loader/Linker notwendig
– Laufzeit-Overhead: großer Teil des Bindeprozesses muss wiederholt werden
● Relokation● Symbolauflösung● statische Initialisierungen● indirekte Daten-Referenzen im PIC● langsamerer Code durch bereits vom PIC belegte Adressierungsregister
– dynamische Bibliotheken sind deutlich größer als statische (Symboltabellen!)
– organisatorisch: Versionsinkompatibilitäten (Semantik der Aufrufe!)
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 25
Techniken: dynam. Aspektweben (1)● Ziel: Aspekte zur Laufzeit laden und entladen
Quelle: [6]
a) Klassisches adaptives System:Nachladen von ModulenDas eigentliche System (base) muss einen Einsprungpunkt im nachgeladenen Modul (m_1) kennen. Unvorhergesehene Anpassungen sind daher schlecht möglich.
a) Klassisches adaptives System:Nachladen von ModulenDas eigentliche System (base) muss einen Einsprungpunkt im nachgeladenen Modul (m_1) kennen. Unvorhergesehene Anpassungen sind daher schlecht möglich.
b) Aspektorientiertes adaptives System:Nachladen von (Aspekt-)ModulenDas nachgeladene Modul kann sich durch den Advice-Mechanismus an bel. Stelle im Basismodul „einklinken“. Das ermöglicht sehr flexible Erweiterungen.
b) Aspektorientiertes adaptives System:Nachladen von (Aspekt-)ModulenDas nachgeladene Modul kann sich durch den Advice-Mechanismus an bel. Stelle im Basismodul „einklinken“. Das ermöglicht sehr flexible Erweiterungen.
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 26
Techniken: dynam. Aspektweben (2)● Fragen zur Semantik:
– Lassen sich alle AOP-Sprachmechanismenauch für dynamische Aspekte nutzen?
● Einfügungen von Typen, …– Worauf sollen die dynamischen Aspekte wirken?
● Nur auf den Code des eigentlichen Systems?● Auch auf andere (Aspekt-)Module, die bereits geladen sind?● Auch auf (Aspekt-)Module, die erst später geladen werden?
● Fragen zur Umsetzung:– Wie manipuliert man bereits geladenen Code zur Laufzeit?
● Funktionsaufrufe umlenken, Funktionen ersetzen, Einfügungen in Klassen– Wie groß ist der Ressourcenverbrauch für die nötige Infrastruktur?– Geht dynamisches Weben auch mit nicht-interpretierten Sprachen?– Wie kann man den Ressourcenverbrauch minimieren?
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 27
Beispiel: Dynamic AspectC++ [6] (1)● Dynamisches Aspektweben mit Einschränkungen
– Module bilden eine „Knowledge Chain“
– Dafür ist aber „Generic Advice“ möglich – essentiell für AOP mit C++
'knows' bedeutet, dass Informationen über die bereits geladenen Module bei der Übersetzung später geladener Module berücksichtigt werden können.
'knows' bedeutet, dass Informationen über die bereits geladenen Module bei der Übersetzung später geladener Module berücksichtigt werden können. Effizient: Der Aspekt 'Logging'
kann im Modul m_2 wie ein normaler statischer Aspekt gewoben werden.
Effizient: Der Aspekt 'Logging' kann im Modul m_2 wie ein normaler statischer Aspekt gewoben werden.
Raffiniert: Bei der Generierung von Advice-Code können die statischen Typinformationen des Zielmoduls genutzt werden.
Raffiniert: Bei der Generierung von Advice-Code können die statischen Typinformationen des Zielmoduls genutzt werden.
aspect TraceResults { advice execution("% %(...)" && !"void %(...)") : after() { cout << tjp->signature() << "returns: " << *tjp->result() << endl;} };
aspect TraceResults { advice execution("% %(...)" && !"void %(...)") : after() { cout << tjp->signature() << "returns: " << *tjp->result() << endl;} };
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 28
Beispiel: Dynamic AspectC++ (2)● Implementierung
– static weaver● Instrumentiert alle potentiellen dynamischen Verbindungspunkte in diesem
Modul, so dass später dynamisch Advice-Code angebunden werden kann.● Webt alle Aspekte der Ebenen 0 bis i statisch.● Generiert Informationen über alle bekannten potentiellen Join Points.● Markiert Zugriffe auf dynamisch eingefügte Attribute im Quelltext.
– dynamic advice generator● Generiert den Advice-
Code für die dyn. Join Points der Ebenen 0bis i-1.
– marker post processor● Transformiert Zugriffe
auf dynamisch eingefügte Attribute.
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 29
Beispiel: Dynamic AspectC++ (3)● Kosten
– Zum Test wurde der Web-Proxy 'Squid' für dynamische Aspekte instrumentiert(alle potentiellen execution Join Points, keine call Join Points)
– Performance● Overhead nur bei lokalen Anfragen feststellbar
– Codegröße (durch 3099 instrumentierte Join Points)● wächst um ca. 8%● Größe der Aspektmodule hängt von Zahl der Join Points ab
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 30
Inhalt● Kontextabhängigkeit
– … auf Betriebssystem-Ebene?
● Varianten der Adaptierbarkeit– Adaptierbare vs. adaptive Systeme– „Große“ vs. eingebettete und Echtzeit-BS
● Dynamische Anpassung– Techniken– Betriebssysteme
● Zusammenfassung
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 31
Betriebssysteme: dynam. Binden● State of the Art: Linux-Kernelmodule
– ähnlich dynamischen Bibliotheken (Anwendungs-Ebene)
Einordnung: dynamisch, Module
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 32
BS: Erweiterbare Kerne● Problem: nicht vertrauenswürdige Module können einen
Systemkern zum Absturz bringen oder lahm legen– unkontrollierte Speicherzugriffe– exzessiver Ressourcenverbrauch (RAM, CPU, Locks, ...)
● Lösungsansatz: Schutz …– durch Isolation
● Sandboxing● Mikrokerne
– durch sichere Sprachen● Modula 3, wie z.B. in SPIN● Java, wie z.B. in JX
● Lösungsansatz: Überprüfung …– der Quelle (z.B. Systemadministrator, BS-Hersteller)– des Verhaltens („Proof-Carrying Code“ [9])
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 33
BS: Mikrokerne (1)● Idee: Verkleinerung der „Trusted Computing Base“ und Schutz
durch Isolation
Hardware
Prozessverwaltung
Virtueller Speicher
E/A und Geräteverwaltung
Interprozesskomm.
Dateisystem
BenutzerBenutzer-modus
PrivilegierterModus
Hardware
MikrokernMikrokern
Virt
uelle
r S
peic
her
Pro
zess
serv
er
Dat
eise
rver
Ger
ätet
reib
er
Ben
utze
r
Benutzer-modus
PrivilegierterModus
...
● Die Aufgabe des Mikrokerns beschränkt sich im Wesentlichen auf die Realisierung des Nachrichtenaustauschs.– Das Konzept sorgt für vergleichsweise einfache (dynamische)
Rekonfigurierbarkeit.
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 34
BS: Mikrokerne (2)● Beispiel: der externe Pager von Mach
● Nutzen: anwendungsspezifische Paging-Strategien können die Performance erheblich steigern
● Problem: viele Kontextwechsel wirken negativ auf die Performance
MikrokernMikrokern
Anwendung Pager
Seiten-fehler
Wieder-aufnahme
Aufrufe zurAdressraum-verwaltung
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 35
BS: Forschungs-Exoten● SPIN [4] (1996)
– Anwendungen können BS-Kern dynamisch erweitern● Anwendungen laufen vollständig im Userspace,● teils im Userspace und in Kernel-Erweiterungen, oder● vollständig im Kernel-Space
→ höhere Performance durch weniger Kontextwechsel– Sicherheit durch eingeschränkte dynamische Bindung
● sichergestellt durch Typsicherheit der Sprache MODULA-3(die bezahlt man natürlich auch zur Laufzeit)
● Namensräume innerhalb des Kerns umschließen eine Menge von Interfaces– Mikrokernel
● emittiert System-Events, auf die Erweiterungen reagieren können● bietet selbst nur grundlegende Dienste an (Thread-, Speicherverwaltung...)
→ selbst Dinge wie Dateisysteme, User-Level-Threads, Netzwerk-Dienste werden in sog. SPINDLES (SPIN Dynamic Loaded ExtensionS) implementiert
Einordnung: dynamisch, untrusted code
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 36
SPIN – Event-Dispatching
Event
Dispatcher
Guards
Handlers
MachineTrap.Syscall(thread, savedState)
isMachThread? isUNIXThread? otherwise
MachHandler UNIXHandler SPINHandler
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 37
SPIN – Event-Dispatching
SPIN Core Services
Shared Extensions
Application Extensions
Thread Mgmt Dev Mgmt VMM Extension Services
Syscall Process Network File System
HTTP Net Video UNIX API Mach API
Kernel
User
UNIX ApplicationUNIX ApplicationUNIX Application Video Server Webserver
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 38
TOSKANA● dynamisches Aspektweben im NetBSD-Kern [8]
– unterstützt before-, after- und around-advice
– für execution-Joinpoints in C-Funktionen
● Architektur:– Im Kern: Bibliothek zur Instrumentierung von Kernfunktionen– Precompiler erzeugt C-Code aus Aspekten, welcher …
● obige Bibliothek verwendet● ein nachladbares Kernelmodul implementiert
– Das Kernelmodul wird kompiliert und als solches geladen● → voller Zugriff auf Kernel-Code und -Daten
Einordnung: dynamisch, Module / Policies
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 39
TOSKANA: Precompileraspect hardware_offload {
pointcut packet_from_to_tcp(struct tcpcb *tp):cflow(tcp_output)&& calls(int tcp_build_datapkt(struct tcpcb *tp , ..));
around ( packet_from_to_tcp ):{
/* ... */}
Aspekt
#include <sys/aspects.h>
ASPECT_NAME("hardware_offload");
void aspect_init(void) {PC *p1;p1 = POINTCUT (
"cflow (tcp_output) &&" \\"calls(int tcp_build_datapkt(struct tcpcb *tp ,..)");
AROUND (p1 , hardware_offload_advice_1);}
ADVICE hardware_offload_advice_1(struct tcpcb *tp) { ...}
PräkompilatBibliotheks-Makros
Pointcut-String zusammenbauen
eigentliches „Weben“ (übernimmt Bibliothek)
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 40
TOSKANA: Funktionsweise
● Weben durch code splicing– Instruktion am Joinpoint wird
durch Sprung auf Advice-Code ersetzt
● Kommandozeilentool weave– verifiziert Joinpoints (gibt es
diese Symbole im Kern?)– lädt kompilierten Aspekt als
Kernelmodul● Eigentliches „Weben“ in aspect_init()
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 41
BS-Ebene: Forschungs-Exoten● SynthesisOS [5] (1992)
– Fokus: hohe Performance ohne Verzicht auf Flexibilität und Sicherheit des Systems
– Kernel-Code-Synthese zur Laufzeit: viel benutzte Routinen werden für bestimmte Situationen optimiert → großer Performance-Gewinn
● Never evaluate something more than once.● Verschiedene Methoden:
– Factoring Invariants (spezialisierte Routinen)– Collapsing Layers (Inlining über Architektur-Schichten hinweg)– Executable Data Structures (Code-Spezialisierung pro Objekt)
– Self-Tuning: Scheduling-Policy passt sich in sehr kurzen Zeitperioden dem Anwendungsverhalten an
– geschickte (optimistic lock-free) Multiprozessor-Synchronisation– erweiterbarer Kernel (enge Kopplung mit Anwendungen)
Einordnung: dynamisch; adaptiv/selbstoptimierend
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 42
BS-Ebene: Forschungs-Exoten
Quelle: [5]
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 43
BS-Ebene: Forschungs-Exoten
Quelle: [5]
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 44
Inhalt● Kontextabhängigkeit
– … auf Betriebssystem-Ebene?
● Varianten der Adaptierbarkeit– Adaptierbare vs. adaptive Systeme– „Große“ vs. eingebettete und Echtzeit-BS
● Dynamische Anpassung– Techniken– Betriebssysteme
● Zusammenfassung
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 45
Fazit (1)● Es existiert eine ganze Reihe von Ansätzen zur dynamischen
Adaptierung von Betriebssystemen.● Aber: Dynamisch adaptierbare (oder gar adaptive)
Betriebssysteme für eingebettete Systeme werden aktuell nur in der Forschung gebaut!– Höherer Ressourcenbedarf steht zu schwacher Hardware gegenüber– Ubiquitäre Systeme sind momentan noch sehr oft
Spezialzwecksysteme, in denen diese Dynamik nicht benötigt wird.
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 46
Fazit (2)● Hardware wird kontinuierlich leistungsstärker
– vgl. PCs der 90er Jahre und heutige Unterhaltungselektronik
● Die Vergangenheit zeigt: BS-Features wandern über dieJahrzehnte von großen zu immer kleineren Systemen– Speicherschutz– virtueller Speicher– Mehrbenutzeretrieb– Dateisysteme– … Adaptierbarkeit?– … Adaptivität?
● … nicht zuletzt, weil die„kleinen“ Systeme immergrößer werden …
Quelle: [2]
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 47
Literatur (1)[1] G. Denys, F. Piessens, and F. Matthijs, A Survey of
Customizability in Operating Systems Research.ACM Computing Surveys, Vol. 24, No. 4, Dec. 2002.
[2] Silberschatz, Operating System Concepts, 5th Edition[3] R. Lea, Y. Yokote, and J. Itoh, Adaptive Operating System
Design using Reflection. 5th Workshop on Hot Topics inOperating Systems, 1995
[4] E.G. Sirer et al., Writing an Operating System with Modula-3.Workshop on Compiler Support for System Software, 1996
[5] H. Massalin, Synthesis: An Efficient Implementation ofFundamental Operating System Services (Dissertation),Columbia University, 1992
[6] R. Tartler, D. Lohmann, W. Schröder-Preikschat, and O.Spinczyk, Dynamic AspectC++: Generic Advice at Any Time. InProceedings of the 8th International Conference on SoftwareMethodologies, Tools and Techniques, 2009.
18.05.2016 SuS: 03.7 Betriebssysteme und Kontext 48
Literatur (2)[7] J. R. Levine, Linkers and Loaders. Morgan-Kaufman, Oct. 1999[8] M. Engel, B. Freisleben, TOSKANA: A Toolkit for Operating
System Kernel Aspects. T. Aspect-Oriented SoftwareDevelopment II: 182-226, Springer, 2006
[9] G. C. Necula and P. Lee. Safe kernel extensions without run-timechecking. In Proceedings of the second USENIX symposium onOperating systems design and implementation (OSDI '96). ACM,
New York, 1996.