i4stubs-all@lists.cs.fau.deAufgabe 0 – Organisation
Transkript zum Übungsvideo (Folien ).
Hallo, herzlich willkommen zu der Lehrveranstaltung Betriebssysteme.
In diesem Video gebe ich einen Überblick, was euch in der Übung erwartet, wie das Semester im präsenzlosen Betrieb ablaufen wird, welche Voraussetzungen ihr mitbringen müsst und wie ihr euch Anmelden könnt.
In der Ü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 von Olaf Spinczyk und Wolfgang Schröder-Preikschat (wosch) 1997 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 tat sich 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 noch auf der Einkernvariante OOStuBS basiert, wird ab 2013 in Betriebssystemtechnik geübt. Und letztes Jahr, 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, dieses Jahr hat Lorenz Kästle im Rahmen seiner Bachelorarbeit mit RiscY StuBS eine RISC-V Variante entwickelt, letztes Jahr hat Maximilian Ott eine ARM Variante für 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 23 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, erstmal 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 folgenden Aufgabe dann zu präemptiven Scheduling umgebaut 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 Pflichtaufgabe habt ihr 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 sparen sollen.
Die derzeitige Pandemie zwingt uns natürlich zu Anpassungen – allerdings wollen wir nicht, dass die Qualität der Veranstaltungen darunter leidet. Vorlesungen werden wöchentlich und Übungen im Zweiwochentakt als Screencast über das Videoportal der Uni sowie als Direktdownload 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. Für jede Aufgabe bekommt ihr im Schnitt weniger als eine halbe Stunde an Videos, aber dort wird dennoch der gesamte Inhalt einer Tafelübung erklärt. Da ich inzwischen das vierte Jahr dabei bin, kenne ich bereits viele der typischen Problemstellen, und hab’ auch versucht diese in den Videos oder den Beschreibungen zu adressieren – für den einen oder anderen können sie aber, je nach Wissensstand, eher trivial wirken. Aber auch für den Fall, dass ihr ein neues Problem entdeckt oder Fragen zu den in den Videos behandelten Themen habt, ist vorgesorgt.
Wir, dass sind Chris und ich, Bernhard, stehen euch jeden Mittwoch ab 12 Uhr zur virtuellen Sprechstunde per Videokonferenz zur Verfügung. Unterstützt werden wir dabei von Harald Böhm, der dies nun auch das dritte Jahr macht, sowie von dieser Gummiente.
Damit wir auch euch kennen lernen, würden wir uns freuen, wenn wir uns direkt in der ersten Vorlesungswoche zu unserer virtuellen Sprechstunde treffen. Auf diesen Wegn können wir euch kennenlernen und ggf. auftretende Fragen direkt beseitigen. Dort erfahrt ihr dann auch, was es mit der Gummiente auf sich hat.
An drei Terminen werden wir in dem Zeitschlitz für die Sprechstunde synchron Zusatzseminare halten, beginnend in der zweiten Vorlesungswoche mit dem Ablauf eines x86er-Bootvorgangs, und somit implizit auch der Geschichte dieser Architektur. Chris wird euch am 25. November zeigen, wie ihr euer Betriebssystem effizient mit dem GNU Debugger entkäfern könnt, und Andi gibt euch am 9. Dezember Hilfestellung für die Assemblerprogrammierung. Da wir in diesen Seminaren auch auf Fragen von euch eingehen und bei GDB und Assembler Lösungen mit euch interaktiv erarbeiten wollen, haben wir uns für diese Veranstaltungsform per Videokonferenz entschieden. 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, das 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 das 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. Letztes Jahr haben wir diese Seminare erstmalig angeboten, und da sie sehr gut angenommen wurden, wollen wir sie trotz Corona euch nicht vorenthalten – wir hoffen, dass die Interaktivität des Formats auch über die Videokonferenz erhalten bleibt.
Und auch die Bearbeitung der Übungsaufgaben wird durch den Virus beeinflusst: Bisher wurde das Betriebssystem in Zweiergruppen entwickelt, in den Rechnerübungen standen wir für Fragen zur Verfügung, und die Abgabe erfolgte durch Präsentation am Testrechner und gemeinsamen Durchsprechen des Quelltextes. Das ist nun in der derzeitigen Situation alles leider so nicht durchführbar.
Wir wollen auch keine halbgaren Versuch, das ohne Änderungen ins Digitale zu übernehmen. Stattdessen orientieren wir uns am Entwicklungsprozess von freien Betriebssystemen. Über die verteilte Versionsverwaltung Git könnt ihr die Aufgaben bearbeiten, und zwar in Zweiergruppen. Bitte trefft euch aber nicht! Sondern nutzt Mail, Chat, Sprach- oder Videokonferenz. Und schreibt euren Code verständlich.
Gutes Softwareengineering ist etwas, was leider zu oft vernachlässigt wird, aber in großen Codebasen essenziell ist. Und auch als Hobbyprojekt begonnene Betriebssysteme haben 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 commitete 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. Da ein Zutritt zum WinCIP zurzeit aber nicht möglich ist, gibt es eine Tastatur-Bildschirm-Maus-Weiterleitung. Ihr könnt also diesen PC komplett fernsteuern, 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 haben wir nun dieses Jahr auf Englisch umgestellt, 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 braucht ihr zu Hause 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 unser Webanmeldefrickelformular – Enterprise Logic (Waffel) notwendig, das ist ab Sonntag, den 25. 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 eines 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 Gruppe ein. Andernfalls nehmt einfach irgendeine Gruppe. Wir werden nach Bedarf weitere Gruppen hinzufügen, bis zur Betreuungskapazitätsgrenze. 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 Masterbranch gesperrt, stattdessen sollt ihr für jede Aufgabe einen eigenen Branch erstellen und dort die Aufgabe lösen.
Der grobe Zusammenhang wird in den Übungsvideos erklärt und sollte natürlich zuerst 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 oder gemeinsam mittels Pair Programming arbeiten – 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 mittels GitLab Merge-Request abgaben. 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 zu, 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. In der Q&A Session 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@lists.cs.fau.de gesetzt, und könnt sie ausgiebig für Fragen nutzen.
Ihr dürft und sollt Probleme auch untereinander diskutieren, dieses Internetz benutzen und einschlägige Wikis konsultieren, Aber gebt keinesfalls euren Code weiter, veröffentlicht und kopiert ihn nicht, Plagiate mögen wir gar nicht, dafür ist zu viel Herzblut in dieser Veranstaltung. Stattdessen könnt ihr konkrete Fragen zu eurem Code über Gitlab Issues in eurem Repo stellen, oder wir wechseln in der Fragestunde einfach in einen Breakoutroom.
Soviel zu unserem Plan, wie wir die Veranstaltung ohne Präsenz durchführen können. Wie gut sich das umsetzen lässt werden wir sehen. Deshalb sind wir auch sehr dankbar über zeitnahes Feedback, egal ob positiv oder negativ. Sagt uns einfach, wenn irgendetwas nicht passt oder nicht gut funktioniert, dann können wir versuchen eine Lösung oder zumindest Alternative zu finden. Und dadurch kann es auch vorkommen, dass wir etwas am Ablauf ändern müssen – wir werden euch aber dann auch entsprechend informieren.
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 4. November um 12:15 Uhr in der Sprechstunde!
