Die Übungen zu Konfigurierbare Systemsoftware sind organisatorisch integriert in die Übungen zu Betriebssystemtechnik. Weitere Informationen finden sich dort.
Im Rahmen der Übungen werden die in der Vorlesung vermittelten Techniken zur Implementierung konfigurierbarer Systemsoftware vertieft:
Semesterbegleitend wird es zwei kleinere Übungsaufgaben (Aufwand je ca. 4–8 Bearbeitungsstunden) zu AspectC++ geben.
Zum Ende des Semesters ist die Anwendung der erlernten Techniken in einer größeren, projektartigen Aufgabe (Aufwand ca. 40 Bearbeitungsstunden) zu einem unserer aktuellen Betriebssystemforschungsprojekte CiAO, Sloth oder VAMOS vorgesehen. (Dies kann z.B. die Portierung von CiAO oder Sloth auf eine neue Hardwarearchitektur sein.)
Bei Fragen zu den Übungen kontaktiert bitte
Isabella
oder
Benjamin
.
Portierung von Sloth auf die PPC-Architektur (2–3 Bearbeiter; Betreuer: Wanja)
Die Hauptaufgabe eines eingebetteten Betriebssystems ist das Einplanen und Einlasten (Scheduling und Dispatching) von Anwendungstasks. Dazu verwaltet normalerweise eine Schedulerkomponente eine Liste von betriebsbereiten Tasks und wählt den Task mit der höchsten (durch die Anwendung konfigurierte) Priorität zum Ablauf aus. Im Sloth-Betriebssystem wird diese Funktionalität in die Interrupt-Hardware verlagert, indem jedem Anwendungstask eine Interruptquelle mit konfigurierter Priorität auf der Hardwareplattform zugewiesen wird und Systemaufrufe wie setReady() auf das Setzen des Pending-Bits der entsprechenden Interruptquelle abgebildet werden. Dadurch übernimmt der Interrupt-Controller zweckentfremdet auch die Task-Verwaltung, was dazu führt, dass Sloth klein (Anzahl Codezeilen, Speicherbedarf RAM, Speicherbedarf ROM) und schnell (Latenzen für Systemaufrufe, Overhead beim Einlasten) ist.
Im Moment läuft Sloth auf dem Infineon TriCore, dem ARM Cortex-M3 und Intel x86. Ziel dieses Projekts ist die Portierung auf den eingebetteten PowerPC MPC5602P (Codename Pictus) von Freescale (Link zum Mikrocontroller-Manual). Der Interrupt-Controller INTC erfüllt alle Anforderungen von Sloth; das Betriebssystem ist intern so strukturiert, um eine Portierung möglichst reibungsfrei zu ermöglichen. Als Testplattform dient ein entsprechend ausgestattetes Starter-Kit. Mehr Informationen zu Sloth mit einer Überblicksbeschreibung finden sich hier, die entsprechend ausführliche Veröffentlichung zu Sloth findet sich hier.
Erweiterung von CiAO um Unterstützung für das Pandaboard (2–3 Bearbeiter; Betreuer: Martin)
In diesem Projekt soll die CiAO Betriebssystemproduktlinie um eine Portierung auf ARM Cortex-A9
Dual-Core Prozessorderivat erweitert werden. Konkret wird in diesem Projekt ein Texas Instruments OMAP4430 Prozessor eingesetzt,
welcher auch in aktuellen Smartphones und Tablets zum Einsatz kommt (z.B. Samsung Galaxy S2).
Für die Umsetzung steht als Entwicklungssystem ein Pandaboard zusammen mit einem
Lauterbach Debugger zur Verfügung.
Portierung von CiAO/IP auf ein AVR-NET-IO-Board (2-3 Bearbeiter; Betreuer:
Jens, Martin)
Im Rahmen dieses Projektes soll die CiAO-Betriebssystemproduktline um eine
Portierung für das AVR-NET-IO-Board
erweitert werden. Dieses ist mit einem ATmega664 Mikrocontroller und einem
ENC28J60 Netzwerkchip ausgestattet. Für den Netzwerkchip soll ein Treiber
entwickelt und in den bestehenden IP-Stack integriert werden.
Als modellhafte Anwendung ist die Benutzerschnittstelle eines netzwerkbasierten,
elektronischen Abrechnungssystems vorgesehen.
Zur Verfügung steht einAVR-NET-IO-Board
und für die Anwendungsentwicklung ein Barcodeleser mit PS/2-Schnittstelle, der
als Eingabegerät dient.
Im Rahmen dieser drei Einzelprojekte soll in Kooperation ein generisches
Tracing-Framework entwickelt werden, welches auswählbare Ereignisse der
Betriebssystemproduktlinien CiAO und OctoPOS mit Hilfe eines GUI-Programmes
graphisch darstellt.
In den ersten beiden Projekten geht es darum den Quellcode der beiden
Betriebssysteme entsprechend zu instrumentieren, um die gewünschten Ereignisse
während des Programmablaufes aufzuzeichnen. Darüber hinaus soll es der Anwendung
möglich sein, die Aufzeichnung der Messdaten zeitlich einzuschränken. Für die
Übertragung der gewonnenen Daten soll eine generische Schnittstelle entwickelt
werden, die von der platformabhängigen Übertragung abstrahiert.
Im dritten Projekt sollen die anfallenden Tracing-Daten ausgewertet und
graphisch visualisiert werden. Dabei sollen Mechanismen zur Interpretation der
betriebssystemspezifischen Daten implementiert werden, die eine aussagekräftige
Visualsierung ermöglichen.
Einbau der Tracing-Infrastruktur in OctoPOS (2 Bearbeiter)
Die OctoPOS-Betriebssystemproduktlinie bildet die Basis der invasiven
Laufzeitsystems (iRTSS). Der
Fokus liegt dabei auf der Entwicklung einer effizienten, leichtgewichtigen und
adaptiven Kontrollflussabstraktion zur optimalen Unterstützung von
Mikroparallelität in Anwendungen für massiv parallele Systeme. Zentrales Mittel
zur Beschreibung von Parallelität stellen dabei die sogenannten iLets dar, die
überwiegend run-to-completion-Semantik haben und von OctoPOS kooperativ
eingeplant werden.
In diesem Projekt geht es darum die Ausführung der einzelnen iLets und die zur
Synchronisation verwendeten Primitiven aufzuzeichnen und in geeigneter Weise dem
Visualsierungstool bereitzustellen.
Die Umsetzung erfolgt in der OctoPOS-Gastebene, die den Funktionsumfang des
Betriebssystems innerhalb eines Linux-Prozesses implementiert.
Einbau der Tracing-Infrastruktur in CiAO (2 Bearbeiter)
In diesem Projekt geht es darum die Einlastung der einzelnen Tasks und ISRs
aufzuzeichnen und in geeigneter Weise dem Visualsierungstool bereitzustellen.
Als Basis dient der bestehende Cortex-M3-Ports von CiAO.
Interpretation und Visualisierung der Tracingdaten aus CiAO und OctoPOS (2
Bearbeiter)
Das zu entwickelnde GUI-Programm soll die zur Verfügung gestellten
Aufzeichnungen geeignet interpretieren und mit Hilfe eines aktuellen
UI-Frameworks (z.B. Qt) visualisieren.
Feature-Qualifikation im Linux-Kern (2–3 Bearbeiter; Betreuer: Reinhard)
Linux bietet über 10000 Merkmalen (engl. "Features"), die vom Benutzer vor der Übersetzungszeit in einem eigens dafür geschriebenem Konfigurationsprogramm konfiguriert werden. Die dabei entstehende Merkmalsselektion kontrolliert im folgenden Übersetzungvorgang welche Dateien und welche darin enthaltenen #ifdef Blöcke letztendlich in den Bauprodukten, dem ladbaren Kernelabbild sowie den zur Laufzeit nachladbaren Modulen, aufgenommen werden.
Während der Benutzer zu jedem Merkmal einen beschreibenden Hilfetext lesen kann, bleiben die technischen Auswirkungen der Merkmalsselektion jedoch weitestgehend unklar. Wieviele Funktionen (also zusätzlicher Code) fügt ein Merkmal ein? Werden Strukturen erweitert (und wenn ja, welche?). Bringt das Merkmal überhaupt Programmcode ein, oder verändert es es nur Kompilerschalter? In diesem Projekt sollen (werkzeuggestützt) Erkenntnisse über die Auswirkungen von Kconfig Merkmalen in Linux gewonnen werden.
