11
Software ubiquitärer SystemeBetriebssysteme und Kontext
Olaf SpinczykArbeitsgruppe Eingebettete Systemsoftware
Lehrstuhl für Informatik 12TU Dortmund [email protected]://ess.cs.uni-dortmund.de/~os/
http://ess.cs.tu-dortmund.de/DE/Teaching/SS2015/SuS/
03.7 – Betriebssysteme und Kontext 22
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 ...
03.7 – Betriebssysteme und Kontext 33
Der Alltagsbegleiter● Beispiel: „Alltagsbegleiter“ PDA/Smartphone
● temporär unterschiedliche Dateisysteme (Speicherkarten)● MP3s für unterwegs● sicherheitsrelevante Daten
Hardware
BS-Kern
Anwendungen
DisplayKeypadWLAN
03.7 – Betriebssysteme und Kontext 44
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
03.7 – Betriebssysteme und Kontext 55
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
03.7 – Betriebssysteme und Kontext 66
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
03.7 – Betriebssysteme und Kontext 77
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
● 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)?
03.7 – Betriebssysteme und Kontext 88
Inhalt● Kontextabhängigkeit
● ... auf Betriebssystem-Ebene?
● Varianten der Adaptierbarkeit● Adaptierbare vs. adaptive Systeme● „Große“ vs. eingebettete und Echtzeit-BS
● Dynamische Anpassung● Techniken
- dynamisches Binden
- dynamisches Aspektweben
● Betriebssysteme- SPIN
- TOSKANA
- Synthesis
● Zusammenfassung
03.7 – Betriebssysteme und Kontext 99
Inhalt● Kontextabhängigkeit
● ... auf Betriebssystem-Ebene?
● Varianten der Adaptierbarkeit● Adaptierbare vs. adaptive Systeme● „Große“ vs. eingebettete und Echtzeit-BS
● Dynamische Anpassung● Techniken
- dynamisches Binden
- dynamisches Aspektweben
● Betriebssysteme- SPIN
- TOSKANA
- Synthesis
● Zusammenfassung
03.7 – Betriebssysteme und Kontext 1010
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
03.7 – Betriebssysteme und Kontext 1111
... auf Betriebssystem-Ebene?● Beispiel: Handy mit
Navigations-Anwendung
● Positionsbestimmung perGPS● 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
03.7 – Betriebssysteme und Kontext 1212
... auf Betriebssystem-Ebene?● Beispiel: PDA mit sicher-
heitsrelevanten Daten
● Kontext: SSID d. 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
03.7 – Betriebssysteme und Kontext 1313
Inhalt● Kontextabhängigkeit
● ... auf Betriebssystem-Ebene?
● Varianten der Adaptierbarkeit● Adaptierbare vs. adaptive Systeme● „Große“ vs. eingebettete und Echtzeit-BS
● Dynamische Anpassung● Techniken
- dynamisches Binden
- dynamisches Aspektweben
● Betriebssysteme- SPIN
- TOSKANA
- Synthesis
● Zusammenfassung
03.7 – Betriebssysteme und Kontext 1414
Varianten der Adaptierbarkeit von BS
adaptierbaresBetriebssystem
Bindung Einheiten
statischkonfigurierbar
dynamischrekonfigurierbar
manuell automatisch
Module Policies untrusted
● 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
03.7 – Betriebssysteme und Kontext 1515
Ausgangspunkt für Forschung (1)
adaptierbaresBetriebssystem
Bindung Einheiten
statischkonfigurierbar
statischkonfigurierbar
dynamischrekonfigurierbar
dynamischrekonfigurierbar
manuellmanuell automatischautomatisch
ModuleModule Policies untrusted
● 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“:
03.7 – Betriebssysteme und Kontext 1616
Ausgangspunkt für Forschung (2)
adaptierbaresBetriebssystem
Bindung Einheiten
statischkonfigurierbar
statischkonfigurierbar
dynamischrekonfigurierbar
manuell automatisch
ModuleModule Policies untrusted
● ... 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
03.7 – Betriebssysteme und Kontext 1717
Im Zentrum der BS-Forschung [1]
adaptierbaresBetriebssystem
Bindung Einheiten
statischkonfigurierbar
statischkonfigurierbar
ModuleModule Policies untrusted
● 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:
dynamischrekonfigurierbar
dynamischrekonfigurierbar
manuellmanuell automatischautomatisch
03.7 – Betriebssysteme und Kontext 1818
Inhalt● Kontextabhängigkeit
● ... auf Betriebssystem-Ebene?
● Varianten der Adaptierbarkeit● Adaptierbare vs. adaptive Systeme● „Große“ vs. eingebettete und Echtzeit-BS
● Dynamische Anpassung● Techniken
- dynamisches Binden
- dynamisches Aspektweben
● Betriebssysteme- SPIN
- TOSKANA
- Synthesis
● Zusammenfassung
03.7 – Betriebssysteme und Kontext 1919
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,...)
adaptierbaresSystem
Bindung Einheiten
statischkonfigurierbar
dynamischrekonfigurierbar
manuell automatisch
Module Policies untrusted
03.7 – Betriebssysteme und Kontext 2020
Inhalt● Kontextabhängigkeit
● ... auf Betriebssystem-Ebene?
● Varianten der Adaptierbarkeit● Adaptierbare vs. adaptive Systeme● „Große“ vs. eingebettete und Echtzeit-BS
● Dynamische Anpassung● Techniken
- dynamisches Binden
- dynamisches Aspektweben
● Betriebssysteme- SPIN
- TOSKANA
- Synthesis
● Zusammenfassung
03.7 – Betriebssysteme und Kontext 2121
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 PIC (Position Independent Code) → Textsegment muss nicht reloziert werden
● GOT (Global Offset Table) für Offsets der globalen Variablen
● PLT (Procedure Linkage Table) für Offsets der Funktionen
03.7 – Betriebssysteme und Kontext 2222
ELF mit GOT und PLTProgramm Bibliothek
Data
Text
PLT
GOT
libx_foo()
Data
Text
PLT
GOT
errno
lazy binding
● Indirektionen, Lade- und Laufzeitoverhead
03.7 – Betriebssysteme und Kontext 2323
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!
03.7 – Betriebssysteme und Kontext 2424
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!)
03.7 – Betriebssysteme und Kontext 2525
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.
03.7 – Betriebssysteme und Kontext 2626
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?
● 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?
03.7 – Betriebssysteme und Kontext 2727
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;} };
03.7 – Betriebssysteme und Kontext 2828
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-Codefür die dyn. Join Points derEbenen 0 bis i-1
● marker post processor
- Transformiert Zugriffe aufdynamisch eingefügteAttribute
03.7 – Betriebssysteme und Kontext 2929
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
03.7 – Betriebssysteme und Kontext 3030
Inhalt● Kontextabhängigkeit
● ... auf Betriebssystem-Ebene?
● Varianten der Adaptierbarkeit● Adaptierbare vs. adaptive Systeme● „Große“ vs. eingebettete und Echtzeit-BS
● Dynamische Anpassung● Techniken
- dynamisches Binden
- dynamisches Aspektweben
● Betriebssysteme- SPIN
- TOSKANA
- Synthesis
● Zusammenfassung
03.7 – Betriebssysteme und Kontext 3131
Betriebssysteme: dynam. Binden● State of the Art: Linux-Kernelmodule
● ähnlich dynamischen Bibliotheken (Anwendungs-Ebene)
Einordnung: dynamisch, Module
03.7 – Betriebssysteme und Kontext 3232
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])
03.7 – Betriebssysteme und Kontext 3333
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
h er
Pro
zess
serv
er
Dat
eise
r ver
Ger
ätet
r eib
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.
03.7 – Betriebssysteme und Kontext 3434
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
03.7 – Betriebssysteme und Kontext 3535
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
03.7 – Betriebssysteme und Kontext 3636
SPIN – Event-Dispatching
Event
Dispatcher
Guards
Handlers
MachineTrap.Syscall(thread, savedState)
isMachThread? isUNIXThread? otherwise
MachHandler UNIXHandler SPINHandler
03.7 – Betriebssysteme und Kontext 3737
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
03.7 – Betriebssysteme und Kontext 3838
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
03.7 – Betriebssysteme und Kontext 3939
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)
03.7 – Betriebssysteme und Kontext 4040
TOSKANA: Funktionsweise
● Weben durch code splicing● Instruktion am Joinpoint wird
durch Sprung auf Advice-Code ersetzt
● K.zeilentool weave● verifiziert Joinpoints (gibt es
diese Symbole im Kern?)● lädt kompilierten Aspekt als
Kernelmodul
● Eigentliches „Weben“ in aspect_init()
03.7 – Betriebssysteme und Kontext 4141
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
03.7 – Betriebssysteme und Kontext 4444
Inhalt● Kontextabhängigkeit
● ... auf Betriebssystem-Ebene?
● Varianten der Adaptierbarkeit● Adaptierbare vs. adaptive Systeme● „Große“ vs. eingebettete und Echtzeit-BS
● Dynamische Anpassung● Techniken
- dynamisches Binden
- dynamisches Aspektweben
● Betriebssysteme- SPIN
- TOSKANA
- Synthesis
● Zusammenfassung
03.7 – Betriebssysteme und Kontext 4545
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.
03.7 – Betriebssysteme und Kontext 4646
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]
03.7 – Betriebssysteme und Kontext 4747
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 SystemDesign 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. (to appear)
03.7 – Betriebssysteme und Kontext 4848
Literatur (2)[7] J. R. Levine, Linkers and Loaders. Morgan-Kaufman, Oct. 1999
[8] M. Engel, B. Freisleben, TOSKANA: A Toolkit for OperatingSystem Kernel Aspects. T. Aspect-Oriented SoftwareDevelopment II: 182-226, Springer, 2006
[9] G. C. Necula and P. Lee. Safe kernel extensions without run-time checking. In Proceedings of the second USENIX symposium on Operating systems design and implementation (OSDI '96). ACM, New York, 1996.
Top Related