Aufgabe 0: C++ Streams

Hallo, herzlich willkommen zu der Lehrveranstaltung Betriebssysteme.

In diesem Video gebe ich einen Überblick, was euch in der Übung erwartet, wie das Semester ablaufen wird, welche Voraussetzungen ihr mitbringen müsst und wie ihr euch Anmelden könnt.

In den Übungen sollen die Inhalte der Vorlesung praktisch vertieft werden, weshalb ihr das nächste halbe Jahr ein eigenes Studentisches Betriebssystem, kurz StuBS, entwickeln dürft – und zwar nicht für irgendwelche "vereinfachte" Hardware, sondern für die x86 Architektur, wie sie von den allermeisten Heim-PCs verwendet wird.

Das Konzept dazu wurde 1997 von Olaf Spinczyk und Wolfgang Schröder-Preikschat (wosch) an der Uni Magdeburg entworfen. Bereits im folgenden Jahr wurde von C auf C++ gewechselt und an die verwendeten Forschungsbetriebsystemen angeglichen – damit Studis anschließend einen einfacheren Einstieg bei Forschungsarbeiten haben. Der Wechsel hat sich auch im Namen niedergeschlagen: Objektorientiertes Studentisches Betriebssystem, kurz OOStuBS.

Das kam gut an, weshalb es wosch und Olaf 2002 mit an unsere Uni gebracht haben. Hier haben sie dann mit Betriebssystemtechnik eine konsekutive Lehrveranstaltung entwickelt, in welcher das Übungsbetriebssystem mittels Aspektorientierter Programmierung auf Lego Mindstorms portiert wurde, also für den Hitachi H8/300L Mikrocontroller. 2008 wurde kurz auf ARM7 gewechselt, um einen Game Boy Advance zu programmieren, bevor das Veranstaltungskonzept überarbeitet wurde.

Und 2009 gab es auch eine größere Änderung in den Übungen zu Betriebssysteme, mit dem MultiProzessorStudenten-Betriebssystem konnten die inzwischen populären Mehrkernsysteme genutzt werden – eine Erweiterung, welche durchaus ganz neue Herausforderungen mit sich brachte. Mit dem Studentischen Betriebssystem mit Isolation, kurz StuBSmI, welches aus Gründen der Komplexität anfangs noch auf der Einkernvariante OOStuBS basierte, wurde ab 2013 in Betriebssystemtechnik geübt. Und 2019 haben wir endlich den Umstieg auf die 64-bit x86 Architektur gewagt, und, gemeinsam mit größeren Aufräum- und Umbauarbeiten, dann auch StuBSmI endlich mehrkernfähig gemacht.

Daneben haben ehemalige Betriebssystemstudis noch weitere Ports entwickelt, letztes Jahr hat Lorenz Kästle im Rahmen seiner Bachelorarbeit mit RiscY StuBS eine RISC-V Variante entwickelt, vorletztes Jahr hat Maximilian Ott eine ARM Variante für den Rasperry Pi gebaut. Und Florian Rommel und Johannes Schilling haben im Rahmen eines Masterprojekts eine Implementierung in Rust erstellt, leider jedoch mit dem Fazit, dass die Sprache in der Betriebssystementwicklung zwar hochinteressant, aber derzeit noch nicht für den Übungsbetrieb geeignet ist.

Unser Übungsbetriebssystem hat somit schon eine schöne Geschichte hinter sich, kleinere und größere Anpassungen gab es in den letzten 24 Jahren regelmäßig, aber die grundlegende Idee ist geblieben: Das Betriebssystem soll auf tatsächlicher Alltagshardware laufen, zum Beispiel euren PC zu Hause.

Allerdings müsst ihr, bevor ihr beginnen könnt, zuerst noch eine wichtige Entscheidung treffen: Wollt ihr in eurer Übung ein Ein- oder Mehrkernbetriebssystem, OOStuBS oder traut ihr euch MPStuBS zu? Falls ihr das Modul Betriebssysteme mit 5 ECTS belegen wollt, reicht OOStuBS. Bei 7,5 ECTS müsst ihr euch aber mit dem Mehrkernbetrieb beschäftigen. Das ist gar nicht mal viel zusätzliches Zeug zum Programmieren, das hält sich sehr in Grenzen. Die Herausforderung liegt hingegen mehr in den Nebenläufigkeitsfehlern, die auftreten können. In MPStuBS muss die Reihenfolge mancher Instruktionen genau überlegt werden, um potenzielle Probleme auszuschließen. Dieser zusätzliche Aufwand rechtfertigt dann auch die extra ECTS.

Das soll euch nun jedoch nicht abschrecken, normalerweise wählen über 90% der Übungsteilnehmer die Mehrkernvariante, und haben daran auch ihren Spaß. Ich kann sie jedem nur empfehlen, da man damit deutlich mehr interessante und realitätsnahe Facetten der Betriebssystementwicklung lernt. Und theoretisch ist es natürlich auch möglich, im Laufe des Semesters von MP- auf OOStuBS "downzugraden",

Unabhängig davon, was ihr wählt, der Ablauf ist bei beiden gleich: Sofern ihr noch nie – oder schon lange nicht mehr – C++ programmiert habt, so haben wir euch bereits eine freiwillige Aufgabe als Fingerübung bereitgestellt, mit der ihr direkt beginnen könnt. Den Großteil könnt ihr dann auch bei der ersten tatsächlichen Aufgabe wiederverwenden – und zwar wenn ihr eurem Betriebssystem beibringt, wie es am Bildschirm eine Ausgabe tätigt. Dazu wird noch die Eingabe über die Tastatur (und optional Maus) implementiert, anfangs mittels regelmäßigen Abfragen des Gerätes, was in der zweiten Aufgabe dann auf Unterbrechungsbetrieb umgestellt wird.

Um die Abarbeitung von Unterbrechungsereignissen zu vereinfachen, führen wir anschließend das Prolog-Epilog-Model ein. Und in Aufgabe 4 zuerst ein kooperatives Scheduling der Anwendungen, welches in der darauf folgenden Aufgabe dann zu präemptiven Scheduling angepasst wird. In der letzten Pflichtaufgabe werden dann Synchronisationsmechanismen implementiert, welche dann in der optionalen Aufgabe 7 verwendet werden können, um eigene Ideen zu realisieren.

Dabei bauen die Aufgaben strikt aufeinander auf, für jede der Pflichtaufgaben habt ihr etwa zwei Wochen Zeit für die Bearbeitung, Von uns gibt es zu Beginn ein Grundgerüst, und wir geben euch zu jeder Aufgabe auch ein Interface vor, sowie Hilfsdateien, die euch langweiliges Abtippen aus einem Datenblatt ersparen sollen.

Aufgrund der Dynamik der Pandemie haben wir uns entschlossen, für dieses Wintersemester zweigleissig zu planen: Diese Veranstaltung, also sowohl Vorlesung als auch der komplette Übungsbetrieb kann remote belegt werden, und – nach Möglichkeit – auch in Präsenz. Sofern die pandemische Lage es zulassen sollte, wird Volkmar die Vorlesung und ich die Tafelübung in Präsenzform im Aquarium abhalten – dabei jedoch auch einen Livestream via BigBlueButton bereitstellen, für alle die nicht an die TechFak kommen können oder wollen. Sollte jedoch die FAU nur noch Onlinebetrieb erlauben, werden wir in den entsprechenden Zeitslots eine Fragestunde via BigBlueButton anbieten, und sonst auf eine asynchrone Lehre umschwenken.

In diesem Fall werden Vorlesungen wöchentlich und Übungen im Zweiwochentakt als Screencast über das Videoportal der Uni sowie auf der Webseite zur Verfügung gestellt. Dabei versuchen wir, die Übungsvideos möglichst angenehm für euch zu machen, also aufgeteilt in kleine themenbezogene Happen, keine langen Einführungen, nicht einmal Begrüßung oder Verabschiedung, sondern möglichst kompakt der relevante Stoff für die Übung, weshalb diese vielleicht zu einem späteren Zeitpunkt bei Unklarheiten nochmals zurate gezogen werden sollten.

Selbstverständlich stehen euch diese Videos auch zusätzlich im Präsenzbetrieb als Nachschlagemöglichkeit zur Verfügung.

Vermutlich wird es bis Semesterbeginn detailliertere Informationen über den rechtlichen Rahmen für den Lehrbetrieb geben, wir werden euch Neuigkeiten dazu über die Webseite und in der Vorlesung sowie Tafelübung mitteilen.

An drei Terminen werden wir in dem Zeitschlitz für die Tafelübung synchron Zusatzseminare halten, beginnend in der dritten Vorlesungswoche mit dem Ablauf eines x86er-Bootvorgangs, und somit implizit auch der Geschichte dieser Architektur. Chris wird euch am 24. November zeigen, wie ihr euer Betriebssystem effizient mit dem GNU Debugger entkäfern könnt, und Andi gibt euch am 8. Dezember Hilfestellung für die Assemblerprogrammierung. Zusätzlich gibt es noch eine Einführung in C++ und GIT, welche bereits jetzt als Video abrufbar sind.

Mit dem Seminar wollen wir helfen, Grundlagen wieder aufzufrischen oder Lücken zu stopfen. Ziel ist, dass ihr damit die Aufgaben besser lösen könnt, beziehungsweise an Fehlern nicht ewig sitzt und verzweifelt – und auch wollen wir damit relevante Zusammenhänge über den Umfang des Vorlesungsstoffs hinaus erörtern, so dass ihr ein besseres Verständnis bekommt. Das bedeutet aber auch, dass diese Seminare freiwillig sind, die Inhalte sind nicht prüfungsrelevant, ihr könnt nach Lust & Laune teilnehmen.

Auch die Bearbeitung der Übungsaufgaben wird durch den Virus beeinflusst: In normalen Semestern wird das Betriebssystem in Zweiergruppen im CIP entwickelt, in den Rechnerübungen stehen wir für Fragen zur Verfügung, und die Abgabe erfolgt durch Präsentation am Testrechner und gemeinsamen Durchsprechen des Quelltextes. Das kann aber unter Umständen dieses Semester so nicht durchführbar sein.

Wir beugen den Fall, dass striktere Maßnahmen ergriffen werden müssen, durch eine Orientierung am Entwicklungsprozess von freien Betriebssystemen vor: Über die verteilte Versionsverwaltung Git könnt ihr die Aufgaben bearbeiten, und zwar in Zweiergruppen, Bei Bedarf auch ohne euch persönlich zu treffen, sondern dann mittels Kommunikation via Mail, Chat, Sprach- oder Videokonferenz. Und idealerweise schreibt ihr auch gleich leicht verständlichen Code.

Gutes Softwareengineering ist etwas, was leider zu oft vernachlässigt wird, aber in großen Codebasen essenziell ist. Und auch so manches als Hobbyprojekt begonnenes Betriebssystem hat schon nach 20 Jahre die 15 Millionen Lines Of Code (LOCs) erreicht. Konkret wollen wir, das ihr euren Quelltext so schreibt, dass sowohl euer Gruppenpartner als auch wir ihn ohne größere Erklärung oder längeres Überlegen verstehen, und ihr auf Schweinereien die C bzw. C++ erlauben lieber verzichtet – wir sind hier nicht der International Obfuscated C Code Contest, wir werden keine Preise für Präprozessor- und Templatevergewaltigungen aushändigen.

Kurze Kommentare bei kritischen Stellen haben noch nie weh getan, verwendet eine sinnvolle Gliederung und verständliche Variablennamen, und orientiert euch an den Vorgaben. Diese kommen übrigens mit einer knappen Coding Style Guideline und einem kleinen Linter, der euch bei den gröbsten Fehlern auf die Finger haut. Ab der ersten Aufgabe wird das auch mittels kontinuierlicher Integration geprüft, zusammen mit einem Build Test, also ob der von euch committete Code überhaupt übersetzt. Das hilft Fehler schnell zu lokalisieren.

Aber wie könnt ihr euer Betriebssystem überhaupt testen? Natürlich geht das bequem per Emulator, aber euer Werk soll selbstverständlich auch auf der echten nackten Hardware laufen. Hierfür haben wir im CIP Testrechner hingestellt, welche euren Kernel über Netzwerkboot laden und ausführen können. Falls ein Zutritt zum WinCIP nicht möglich ist, kann auch die Tastatur-Bildschirm-Maus-Weiterleitung genutzt werden, mit der ihr die PCs komplett fernsteuern könnt, zum Beispiel über euren Webbrowser aus. Natürlich inklusive Strom trennen, falls euer StuBS hängt.

Falls wir euer Interesse geweckt haben, und ihr nun anfangen wollt: Was müsst ihr für den Übungsbetrieb mitbringen? Grundkenntnisse in der Systemprogrammierung, also zum Beispiel Systemprogrammierung 1 (SP1), setzen wir voraus, und gehen somit davon aus, dass ihr noch etwas C könnt. Die Vorlesung und Übung sind auf Deutsch, aber die komplette Aufgabenstellung und Dokumentation sind in englischer Sprache, um zum einen einheitliche Begriffe mit Datenblättern und dem Intel Manual zu gewährleisten, und zum anderen natürlich, weil dies die typische Sprache bei großen OpenSource-Projekten ist.

Außerdem wollen wir in den Übungen keine Code Monkeys trainieren, es ist vor allem in den späteren Aufgaben nicht nötig viel Quelltext zu schreiben – aber auch wenige Zeile können ihr Tücken haben, und das Fehlersuchen wird erfahrungsgemäß ein gutes Stück Zeit in Anspruch nehmen, entsprechend ist es hilfreich, wenn ihr etwas Frusttoleranz mitbringt. Wenn es euch aber wider Erwarten zu einfach ist, so haben wir bei manchen Aufgaben freiwillige Zusatzaufgaben, die euch dann hoffentlich etwas fordern – und eurem StuBS neue Features hinzufügen.

Für die Bearbeitung der Aufgaben von zu Hause aus braucht ihr mindestens ein internetfähiges Endgerät mit einem halbwegs aktuellen Webbrowser, idealerweise habt ihr natürlich einen 64 bit x86 PC mit unixoider Umgebung. Einen CIP Account solltet ihr bereits haben, falls jedoch noch nicht, so könnt ihr diesen bequem online aktivieren.

Für die Übung ist eine Anmeldung über Waffel notwendig, das ist ab Sonntag, den 10. Oktober möglich. Bitte überlegt euch bis dahin, ob ihr OOStuBS oder MPStuBS entwickeln wollt. Es gibt technisch bedingt jeweils einen unterschiedlichen Kurs – bitte meldet euch nur für einen von beiden an!

Außerdem sollen die Aufgaben wie bereits erwähnt in Zweiergruppen gelöst werden, aber die Coronasituation erschwert etwas die Gruppenfindung. Deshalb haben wir zur Anmeldung bereits Gruppen vordefiniert: Sofern ihr bereits einen Partner habt, tragt euch möglichst zeitgleich in dieselbe Waffel-Gruppe ein. Andernfalls nehmt einfach irgendeine Gruppe. Wir werden nach Bedarf weitere Gruppen hinzufügen, bis zur Betreuungskapazitätsgrenze – welche dieses Jahr aufgrund gekürzter Mittel leider relativ niedrig ist. Falls ihr keinen Platz bekommen habt, schreibt uns bitte eine Mail, mit eurem Login und der gewünschten Variante, gegebenenfalls auch den Übungs-Partner und wir setzen euch auf die Warteliste.

Bei erfolgreicher Anmeldung wird für euch innerhalb von 24 Stunden ein Übungsgruppenrepo in unserem GitLab angelegt, mit ein paar Vorgaben von uns im Masterbranch. Für euch ist der Schreibzugriff auf den Masterzweig gesperrt, stattdessen sollt ihr für jede Aufgabe einen eigenen Zweig erstellen und dort die Aufgabe lösen.

Der grobe Zusammenhang wird in der Tafelübung und den Übungsvideos erklärt und sollte natürlich zuerst besucht bzw. angeschaut werden, die konkrete Aufgabenbeschreibung steht dann zusammen mit der Dokumentation und weiteren Zusatzinformationen auf der Webseite.

Wie ihr dabei in der Gruppe arbeitet bleibt euch überlassen, ihr könnt entweder separat Teilprobleme lösen, gemeinsam im CIP unter Einhaltung aller Coronabestimmungen arbeiten oder remote mittels Pair Programming – Werkzeuge gibt es viele dafür, wir haben euch dazu Beispiele auf der Webseite verlinkt, schaut was am besten für euch funktioniert, probiert es einfach aus. Aber am Schluss soll natürlich jeder von euch das eigene Betriebssystem komplett verstehen.

Wenn ihr eure Aufgabenlösung ausgiebig getestet habt, und zwar nicht nur im Emulator, sondern auch auf unserer Testhardware, und alle Anforderungen der Angabe umgesetzt habt, könnt ihr entweder in der Rechnerübung persönlich oder mittels GitLab Merge-Request remote abgeben. Wir kommentieren euren Code, haben vielleicht Rückfragen oder finden gar Fehler, die ihr dann noch ausbessern müsst, bevor wir eure Abgabe akzeptieren und dann in den Masterbranch mergen. Außerdem fügen wir für die nachfolgende Aufgabe noch ein paar neue Dateien hinzu, danach könnt ihr davon einen neuen Zweig erstellen und mit der Bearbeitung der nächsten Aufgabe beginnen.

Sollten Fragen und Probleme aufkommen, die ihr auch nach etwas überlegen nicht selbst beantworten könnt, schaut bitte zuerst in die Aufgabenstellung, dort stehen oft schon Hinweise, sowie in die FAQ. Im Anschluss an die Tafelübung am Mittwoch habt ihr unsere volle Aufmerksamkeit, aber auch über Chat kann euch von uns oder anderen Studis geholfen werden. Außerdem werdet ihr mit eurer Waffelanmeldung auf die Mailingliste i4stubs-all gesetzt, und könnt sie ausgiebig für Fragen nutzen.

Ihr dürft und sollt Probleme auch untereinander diskutieren, dieses Internet benutzen und einschlägige Wikis konsultieren, Aber gebt keinesfalls euren Code weiter, veröffentlicht und kopiert ihn nicht, bei Plagiate machen wir kurzen Prozess. Stattdessen könnt ihr konkrete Fragen zu eurem Code in der Rechnerübung oder alternativ remote über Gitlab Issues in eurem Repo stellen.

Auf ein schönes Semester mit eurem Einstieg in die Betriebssystementwicklung, meldet euch bitte für die Übung in Waffel an, und wir sehen uns dann am 20. Oktober um 14:15 Uhr in der Tafelübung – entweder in Präsenz vor Ort oder virtuell mittels BigBlueButton!