Projektkampagnen

Ein Betriebssystem befindet sich zwischen zwei Fronten: Einerseits ("oben") die Maschinenprogramme der Anwendungen mit ihren teils sehr unterschiedlichen funktionalen und nichtfunktionalen Anforderungen und andererseits ("unten") die Rechnerhardware, deren Merkmale und Gerätschaften den Anwendungen idealerweise "ungefiltert" und "geräuschfrei" zur Verfügung gestellt werden sollen. Allerdings kann ein Allzwecksystem in keiner seiner Funktionen so effizient sein wie ein System, das speziell für einen bestimmten Zweck entwickelt wurde und weniger anspruchsvolle Anwendungen dürfen verlangen, dass sie nicht gezwungen werden, für die verbrauchten Ressourcen durch die nicht benötigten Funktionen zu zahlen. So ist es nicht ungewöhnlich, dass große Systeme, einmal in Betrieb genommen, in der Regel häufigen Änderungen unterliegen --- eben gerade auch deshalb, um eine höhere Passgenauigkeit an sich ändernde Anwendungsanforderungen zu erreichen.

Das ideale Betriebssystem bietet genau das, was für die jeweilige Anwendung benötigt wird --- nicht mehr und nicht weniger, aber eben auch in Abhängigkeit von den Merkmalen der Hardwareplattform. Ein solches Ideal ist jedoch, wenn überhaupt, nur für den Einprogrammbetrieb realistisch. Bei Mehrprogrammbetrieb müssten die verschiedenen Anwendungen schon "hinreichend gleiche" funktionale und nichtfunktionale Anforderungsmerkmale aufweisen, um keine der Anwendungen mit den Gemeinkosten (overhead) zu belasten, die die nicht benötigten Funktionen mit sich bringen. Ein Betriebssystem mit diesen Eigenschaften fällt in die Kategorie Spezialsystem (special purpose operating system), es ist zugeschnitten auf die Bedürfnisse von Anwendungen eines bestimmten Typs.

Im Gegensatz dazu steht das Allzwecksystem (general purpose operating system), wo letztlich nur zu hoffen ist, dass eine Anwendung nicht mit zu hohen Gemeinkosten durch die nicht benötigten Funktionen belastet wird. Hier kann immerhin versucht werden, das "Hintergrundrauschen" (background noise) im Betriebssystem bei Bedarf zu minimieren --- idealerweise in diesem Fall mit unterschiedlichem "Rabatt" je nach Programmtyp. Das Betriebssystem müsste dann mit weniger anspruchsvollen Anwendungen nicht nur dynamisch von unnötigem Ballast befreit werden und schrumpfen können, sondern auch in die Lage versetzt werden, bei anspruchsvolleren Anwendungen mit dafür nötigen und zusätzlichen Funktionen wieder anzuwachsen. Spezialisierung eines Betriebssystems in Abhängigkeit vom jeweiligen Anwendungsfall bedeutet letztlich funktionelle Abmagerung und Anreicherung, wozu ein geeigneter Systemsoftwareentwurf zwar wünschenswert ist, sich aber gerade bei Altsoftware (legacy system) oft nicht mehr umsetzen lässt.

Ein Umstand für die Spezialisierung eines Betriebssystems bezieht sich auf explizit "von außen her" initiierte Maßnahmen. Dies betrifft einerseits ausgewählte Systemaufrufe und andererseits Vorgänge wie das Urladen (bootstrap) sowie das Laden von Maschinenprogrammen, Betriebssystemkernmoduln oder von Programmen, die in sandkastenartigen virtuellen Maschinen innerhalb des Betriebssystemkerns zur Ausführung kommen sollen. Diese Form der Spezialisierung ermöglicht ebenfalls die dynamische Generierung von gezielten Schutzmaßnahmen in Folge von besonders vulnerablen Betriebssystemoperationen, wie dem Laden von externen Modulen des Betriebssystemkerns. Der andere ausschlaggebende Umstand für die Spezialisierung eines Betriebssystems bezieht sich auf implizit "von innen heraus" initiierte Maßnahmen. Dies betrifft mögliche Reaktionen eines Betriebssystems auf erst zur Laufzeit wahrnehmbare Änderungen im eigenen Laufzeitverhalten, um daraufhin etwa die Strategien einer Ressourcenverwaltung der jeweiligen Arbeitslast anzupassen und entsprechende Systemsoftware in das bestehende System nahtlos einzupassen.

Projektfokus ist die dynamische Betriebssystemspezialisierung, ausgelöst durch extrinsische und intrinsische Ereignisse. Im Vordergrund stehen Verfahren und Techniken, die (a) unabhängig von einem bestimmten Programmierparadigma oder Hardwareansatz sind und (b) auf bedarfssynchrone (just in time, JIT) Übersetzung von Teilen des Betriebssystem(kern)s basieren, um im bereits laufenden Betrieb bedarfsweise (on demand) zu ladende oder vorausschauend (anticipatory) zu ersetzende Betriebssystemprogramme den jeweiligen Gegebenheiten an den "Betriebssystemfronten" anzupassen. Untersuchungsgegenstand sind bestehende Allzwecksysteme wie etwa Linux.

Das Vorhaben entwickelt ein neuartiges Paradigma, um Prozessmigration in Mehrkern-Echtzeitsystemen zeitlich vorhersagbar zu gestalten. Kern des Ansatzes ist das Konzept der migrationsgewahren Laufzeitumgebung (migration-aware real-time executive), in welcher Migrationsentscheidungen anstatt auf globalen Lastparametern systematisch auf Grundlage von Hinweisen der unter (strikten) Echtzeitbedingungen ablaufenden Maschinenprogramme der Anwendungsebene getroffen werden. Diese sogenannten Migrationshinweise (migration hints) betreffen zeitliche und räumliche Aspekte von Echtzeitprozessen, sie markieren potentielle Migrationspunkte in dem betreffenden nichtsequentiellen (mehrfädigen) Maschinenprogramm. Sie befähigen das Betriebssystem Entscheidungen zu treffen, die sich möglichst günstig auf die Vorhersagbarkeit und Leistungsfähigkeit des Gesamtsystems auswirken. Konkret nimmt das Vorhaben an, dass anwendungsspezifische Hinweise auf zulässige und besonders günstige Programmpunkte für die Migration eine aufwandsarme Möglichkeit darstellen, um bestehende Echtzeitsysteme und Techniken hinsichtlich Antwortzeit und Planbarkeit zu verbessern. Den Untersuchungsgegenstand stellen Mehrkern-Plattformen mit heterogenen Speicherarchitekturen dar. Im Fokus stehen die durch Migration verursachten Verwaltungsgemeinkosten, welche von Speicherort und Umfang der Migrationsdaten abhängig sind. Diese über die Ausführungszeit variierenden Kosten werden werkzeuggestützt durch Methoden der statischen Analyse zur Entwurfszeit ermittelt und zur Identifikation von Migrationspunkten mit gut vorhersagbaren Kosten genutzt. Ausgehend von existierenden Echtzeitbetriebssystemen entwickelt das Vorhaben migrationsgewahre Varianten, welche das Wissen über diese günstigen Migrationspunkte durch speziell angepasste Schnittstellen und automatisch präparierte Anwendungsprogramme in Form von Migrationshinweisen zur Verfügung gestellt bekommen, um somit zur Laufzeit möglichst positive Entscheidungen für das Gesamtsystem treffen zu können.