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.)
Varianten schätzen/zählen/raten in Linux (2 Bearbeiter; Betreuer: Daniel)
Linux bietet (in v3.2) etwa 12000 Merkmale ("Features"), die vom Benutzer vor der Übersetzungszeit in einem eigens dafü geschriebenem Konfigurationsprogramm konfiguriert werden. Während dieses Merkmalmodel in der Literatur bereits gut untersucht wurde, ist vollkommen unbekannt, wie viele Varianten sich daraus tatsächlich ableiten lassen. Das Problem gilt komplexitätstheoretisch als "schwierig" wegen des exponentiellen Aufwands entsprechender Traversierungsalgorithmen. Durch die besondere Struktur des Mermalmodels von Linux (sehr flach, viele optionale Merkmale ohne "cross-tree constraints") könnten es aber dennoch möglich sein, die Variantenanzahl zu ermitteln oder zumindestens gut abzuschätzen.
Im Rahmen des Projekts soll ein entsprechender Algorithmus entwickelt und erprobt werden und in die VAMOS-Werkzeugkette integriert werden.
Bearbeiter: Valentin, Stefan
Webbasierte Totblock-Visualisierung für Linux (2 Bearbeiter; Betreuer: Manuel, Stefan, Daniel)
Die 12000 Merkmale von Linux v3.2 werden unter anderem implementiert durch etwa 89000 #ifdef Blöcke im Quellcode. Im VAMOS-Projekt konnten wir zeigen, dass viele dieser Blöcke "tot" (in keiner Konfiguration selektiert) oder "untot" (immer selektiert) sind. Das undertaker-Werkzeug findet derartige Blöcke, und stellt sie in Form eines (textbasierten) Defektreports bereit.
Ziel des Projektes ist tote und untote Blöcke ansprechend im Code zu visualisieren, so dass Kernelentwickler einfach über die VAMOS-Webseite darauf zugreifen können. Dabei soll klar werden welche Defektart gefunden wurde und wie dieser Defekt zustande kam. Zu diesem Zweck soll GitWeb erweitert werden, so dass Defektreports auf Wunsch eingeblendet werden (z.B. durch andere Hintergrundfarbe).
Merkmale, #ifdef-Blöcke und andere Quellen der Variabilität werden durch die VAMOS-Werkzeuge einer Analyse (z.B. Totblockanalyse) zugänglich gemacht, indem sie in ein einheitliches Format extrahiert werden: Aussagenlogische Formeln in KNF. Die dabei entstehenden Formeln werden jedoch teilweise sehr groß, da sie viele unnötige Redundanzen beinhalten, was die Laufzeit der entsprechenden Werkzeuge (insbesondere des SAT-Solvers) erheblich beeinträchtigt und die Nachvollziehbarkeit (z.B. warum genau ein Block tot ist) erschwert.
Ziel des Projekts ist, die aus dem Konfigurationssystem extrahierten aussagenlogischen Formeln, die anzeigen unter welchen Bedingungen ein spezifisches Symbol auswählbar ist, zu minimieren. Hierzu soll ein geeignete Minimierer für KNF-Formeln gesucht und in die VAMOS-Werkzeugkette integriert werden. Abschließend soll evaluiert werden, ob sich die Laufzeit der VAMOS-Werkzeuge so verbessern lässt.
Bearbeiter:
Erweiterung der Sloth-Implementierung auf einem Embedded PowerPC (2 Bearbeiter, Betreuer: Rainer)
Im Sloth-Betriebssystemkern
wird das Einplanen und Einlasten (Scheduling und Dispatching) von
Anwendungstasks in die Interrupt-Hardware ausgelagert, indem jedem Task eine
Interruptquelle mit konfigurierbarer Priorität zugeordnet wird. Systemaufrufe
werden auf entsprechende Funktionalität des Interrupt-Controllers abgebildet,
so dass beispielsweise das Aktivieren eines Tasks lediglich dem Setzen des
Pending-Bits entspricht. Die eigentliche Auflösung der Prioritäten und die
Auswahl des laufenden Tasks übernimmt die Hardware, so dass der Sloth-Kern in
Bezug auf Codezeilen kompakt implementiert ist und einen geringen
Speicherbedarf für RAM und ROM aufweist.
Implementierungen von Sloth nutzen die Besonderheiten der jeweiligen
Hardwareplattform gezielt aus. Unterstützt werden bereits mehrere
Architekturen, unter anderen dem Infineon TriCore, dem ARM Cortex-M3 und ein
initialer Port für den Freescale
MPC5602P. Auf dem letzteren werden allerdings bisher nur die Basic Tasks der
OSEK-Schnittstelle unterstützt. In diesem Projekt soll die Implementierung um
die Unterstützung für Extended Tasks erweitert werden (Sleepy Sloth).
Als Plattform für die Implementierung steht ein
MPC5602P Starter-Kit
zur Verfügung, dessen Mikrocontroller im entsprechenden Datenblatt
dokumentiert ist.
Bearbeiter: Carolin und Merlin
Hardware-basierte Taskisolation für Sloth auf dem ARM Cortex-M3 (2 Bearbeiter, Betreuer: Rainer)
In eingebetten Betriebssysstemen mit Bedacht auf Betriebssicherheit (Safety)
werden die verschiedenenen Tasks einer oder mehrerer Anwendungen voneinander
isoliert, um gegenseitige Beeinträchtigung und dadurch ausgelöste
Fehlfunktionen auszuschließen. Zur Eingrenzung der Speicherzugriffe gibt es auf
Mikrocontrollern dafür eine Speicherschutzeinheit (Memory Protection Unit, kurz
MPU), die nur Zugriffe auf zuvor festgelegte Speicherbereiche zulässt. Das
Betriebssystem konfiguriert diese Bereiche bei jedem Kontextwechsel zwischen
Tasks entsprechend, so dass nur auf die Daten zugegriffen werden kann, die
diesem Task vom Anwendungsentwickler zugeordnet wurden. Durch die Ausführung
der Anwendungstasks auf einer niedrigeren Berechtigungsstufe wird die
Umprogrammierung der MPU zur Laufzeit verhindert.
In der originalen Implementierung von Sloth
werden alle Tasks und der Kern ohne Isolation auf derselben Berechtigungsstufe
ausgeführt. Inzwischen existiert aber bereits eine Implementierung des
Speicherschutzes für den Infineon TriCore. Diese Implementierung soll in diesem
Projekt für den Sloth-Kern auf dem ARM Cortex-M3 mit effizienter Ausnutzung der
MPU-Hardware portiert werden.
Portierung der Hau-den-Lukas-Steuerung auf Sloth (2 Bearbeiter, Betreuer: Daniel)
Bei Hau den Lukas handelt es sich um eine Art elektronischer Variante der bekannten Jahrmarktattraktion.
Im Gegensatz zum
traditionellen Hau den Lukas sorgt hier nicht Muskelkraft, sondern
Elektrizität und Magnetismus für die Beschleunigung des Gewichts. Das
Gewicht ist ein Metallzylinder der durch eine Plexiglasröhre geführt
wird. An der Plexiglasröhre sind in regelmäßigen Abstand Spulen
angebracht, die durch ihre magnetische Wirkung den Zylinder nach oben
ziehen können. Oberhalb einer jeden Spule befindet sich eine
Lichtschranke, mit deren Hilfe man den Ausschaltzeitpunkt der Spule
bestimmen kann.
Als Plattform für die Steuerung ist ein TriCore TC1796 von Infineon im Einsatz.
Die dazugehörige Steuerungssoftware existiert bereits für verschiedene
kommerzielle und akademische Echtzeitbetriebssysteme, und soll in Rahmen dieses
Projekts als Sloth-Anwendung umgesetzt
werden, sowie hinsichtlich der Latenzen evaluiert und mit einer existerenden
Portierung verglichen werden.
Bearbeiter: Bernhard und Andreas
Portierung von CiAO/IP auf das AVR-NET-IO-Board (2 Bearbeiter; Betreuer:
Jens, Martin)
Im Rahmen eines KSS-Projektes aus dem vergangenen Jahr, wurde die CiAO-Betriebssystemproduktline um eine Portierung für das AVR-NET-IO-Board erweitert.
Nun soll für den vorhandenen Netzwerkchip 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 ein AVR-NET-IO-Board, mit einem ATmega664 Mikrocontroller und einem ENC28J60 Netzwerkchip, und für die Anwendungsentwicklung ein Barcodeleser mit PS/2-Schnittstelle, der als Eingabegerät dient.
Die OctoPOS-Betriebssystemproduktlinie bildet die Basis des 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.
Die NAS Parallel Benchmarks der NASA dienen als Standartbenchmarks zur Evaluation des Performanz von parallenen Systemen.
Im Rahmen dieses Projektes sollen ausgewählte Algorithmen aus den NAS Parallel Benchmarks als Anwendung auf dem OctoPOS-Betriebssystem implementiert werden.
Die Umsetzung erfolgt in der OctoPOS-Gastebene, die den Funktionsumfang des Betriebssystems innerhalb eines Linux-Prozesses implementiert.
Erstellen eines Tracing-Frameworks (Betreuer: Martin, Jens)
Im Rahmes eines KSS-Projektes aus dem vergangenen Jahr wurde die CiAO-Betriebssystemproduktlinie um einige konfigurierbare Tracing-Aspekte erweitert, um ausgewählte Ereignisse zur Laufzeit aufzeichnen zu können.
Die gesammelten Daten sollen nun mit Hilfe eines zu entwickelnden GUI-Programmes interpretiert und visualisiert werden.
Die Umsetzung soll mit Hilfe der CiAO-Gastebene erfolgen. Die GUI soll mit Hilfe eines aktuellen UI-Frameworks (z.B. Qt) implementiert werden.