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 STUPS, 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 Spinzig und Bosch an der Uni Magdeburg entworfen.
Bereits im folgenden Jahr wurde von C auf C++ gewechselt und an die verwendeten Forschungsbetriebssysteme
angeglichen, damit Studis anschließend einen einfacheren Einstieg bei Forschungsarbeiten
haben.
Der Wechsel hat sich auch im Namen niedergeschlagen, objektorientiertes studentisches Betriebssystem,
kurz OSTUPS.
Das kam gut an, weshalb es Bosch und Olaf 2002 mit an unsere Uni gebracht haben.
Hier haben sie dann mit Betriebssystem Technik eine konsekutive Lehrveranstaltung entwickelt,
in welcher das Übungsbetriebssystem mittels aspektorientierter Programmierung auf Lego
Mindstorms portiert wurde, also für den Hitachi H8300L 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 denen
Multiprozessor-Studentenbetriebssystemen 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 STUPSME, welches aus Gründen
der Komplexität anfangs noch auf der Einkernvariante OO STUPS basierte, wurde ab 2013 in Betriebssystem
Technik geübt.
Und 2019 haben wir endlich den Umstieg auf die 64-bit x86 Architektur gewagt und gemeinsam
mit größeren Aufräumen und Umbauarbeiten dann auch STUPSME endlich mehr kernfähig
gemacht.
Daneben haben ehemalige Betriebssystemstudies noch weitere Ports entwickelt.
Letztes Jahr hat Lorenz Kessle im Rahmen seiner Bachelorarbeit mit Risky STUPS eine
RISC-V Variante entwickelt.
Vorletztes Jahr hat Maximilian Ott eine ARM Variante für den Raspberry 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 hoch
interessant, 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 gleich geblieben.
Das Betriebssystem soll auf tatsächlicher Alltags-Hardware laufen, zum Beispiel eurem
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 mehr kein Betriebssystem, o STUPS oder traut ihr
euch mPSTUPS zu?
Falls ihr das Modul Betriebssysteme mit 5 ECTS belegen wollt, reicht o STUPS.
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 mPSTUPS muss die Reihenfolge mancher Instruktionen genau überlegt werden, um potenzielle Probleme
auszuschließen.
Und 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 o STUPS down zu graden.
Unabhängig davon was ihr wählt, der Ablauf ist bei beiden gleich.
Sofern ihr noch nie oder schon lang 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 wieder verwenden.
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-Modell ein.
Und in Aufgabe 4 zuerst ein kooperatives Scheduling der Anwendungen, welches in der darauffolgenden
Aufgabe dann zu präemptiven Scheduling angepasst wird.
In der letzten Pflichtaufgabe werden dann die 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 Hilfstateien, die euch langweiliges Abtippen aus einem Datenblatt
ersparen sollen.
Aufgrund der Dynamik der Pandemie haben wir uns entschlossen, für dieses Wintersemester
zweigleisig 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 folgend die Vorlesung und ich die Tafelübung
hier im Aquarium in Präsenzform abhalten, dabei jedoch auch einen Livestream via BigBlo
Button zur Verfügung stellen, für alle die nicht an die TechFac kommen können oder wollen.
Sollte jedoch die FAU nur noch einen Onlinebetrieb erlauben, werden wir in den entsprechenden
Zeitslots eine Fragestunde via BigBlo Button anbieten und sonst auf die asynchronere Lehre
umschwenken.
In diesem Fall werden Vorlesungen wöchentlich und Übungen im Zwei-Wochen-Takt als Screencast
über das Videoportal der Uni sowie auf der Website zur Verfügung gestellt.
Dabei versuchen wir, die Übungsvideos möglichst angenehm für euch zu machen, also aufgeteilt
in kleine themenbezogene Hubs, keine lange Einführung, nicht mal Begrüßung oder Verabschiedung,
sondern möglichst kompakter relevante Stoffe für die Übung, weshalb diese vielleicht
zu einem späteren Zeitpunkt bei Unklarheiten nochmals zu Rate 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 detaillierte Informationen über den rechtlichen Rahmen
für den Lehrbetrieb geben.
Wir werden euch Neuigkeiten dazu über die Website und in der Vorlesung sowie Tafelübung
mitteilen.
An drei Terminen werden wir in dem Zeitschlitz für die Tafelübung Synchronzusatzseminare
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 Andy gibt euch am 8. Dezember Hilfestellung für die Assembler-Programmierung.
Zusätzlich gibt es noch eine Einführung im 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 es, dass ihr damit die Aufgaben besser lösen könnt, bzw. an Fehler nicht ewig
sitzt und verzweifelt.
Und auch wollen wir damit relevanten Zusammenhänge über den Umfang des Vorlesungsstoffs hinaus
erörtern, sodass 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 und Laune teilnehmen.
Auch die Bearbeitung der Übungsaufgaben wird durch den Virus beeinflusst.
In normalen Semestern wird das Betriebssystem in Zweiergruppen im ZIP entwickelt.
In den Rechneü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 auch unter Umständen dieses Semesters 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.
Gute Software Engineering ist etwas, was leider zu oft vernachlässigt wird, aber in großen
Codebassen essentiell ist.
Und auch so manches als Hobbybrick begonnenes Betriebssystem hat schon nach 20 Jahren die
15 Millionen Lines of Code erreicht.
Konkret wollen wir, dass 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 obfiskeite C-Code-Kontest, wir werden keine Preise für
Präprozesse und Template-Vergewaltigungen aufsendigen.
Kurze Kommentare bei kritischen Stellen haben noch nie wehgetan.
Verwendet eine sinnvolle Gliederung und verständliche Variablenamen und orientiert euch bitte an
den Vorgaben.
Diese kommen übrigens mit einer knappen Coding Style Guideline und einem kleinen Linder,
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 kommittete 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 einen ZIP-Testrechner hingestellt, welche ihr euren Kernel über Netzwerkboot
laden und ausführen könnt.
Falls ein Zutritt zum WinZIP nicht möglich ist, kann auch die Tastaturbildschirm-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 mal hängt.
Falls wir euer Interesse geweckt haben und ihr nun anfangen wollt, was müsst ihr eigentlich
für den Übungsbetrieb mitbringen?
Grundkenntnisse in der Systemprogrammierung, also z.B.
SP1 setzen wir voraus und gehen somit davon aus, dass ihr noch etwas sehen könnt.
Die Vorlesungen und Übungen sind auf Deutsch, aber die komplette Aufgabenstellung und Dokumentation
sind in englischer Sprache, um zum einen einheitliche Begriffe mit Datenblättern und dem Intel-Manuell
zu gewährleisten und zum anderen natürlich, weil dies die typische Sprache bei großen
Open-Source-Projekten ist.
Außerdem wollen wir in den Übungen keine Code-Mangels trainieren.
Es ist vor allem in den späteren Aufgaben nicht nötig, viel Queltex zu schreiben, aber
auch wenige Zeilen können in ihren 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 wie erwartet so einfach ist, so haben wir bei manchen Aufgaben freiwillige
Zusatzaufgaben, die euch dann hoffentlich etwas fordern und eurem Stubs neue Features
beibringen.
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 x86er PC mit unixoider Umgebung.
Einen ZIP-Account solltet ihr bereits haben, falls jedoch nicht, so könnt ihr diesen bequem
online aktivieren.
Für die Übung ist eine Anmeldung über Waffeln notwendig.
Das ist ab Sonntag, den 10.
Oktober möglich.
Bitte überlegt euch bis dahin, ob ihr O-Stubs oder MP-Stubs 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 Corona-Situation 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 Waffelgruppe
ein.
Andernfalls nimmt einfach irgendeine Gruppe.
Wir werden nach Bedarf weitere Gruppen hinzufügen, bis zur Betreuungskapazitätsgrenze, welche
jedoch 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 Übungspartner und wir setzen euch dann
auf die Warteliste.
Bei erfolgreicher Anmeldung wird für euch innerhalb von 24 Stunden ein Übungsgruppen-Repo
in unserem GitLab angelegt, mit ein paar Vorgaben von uns im Master-Branche.
Vor euch ist der Schreibzugriff auf die Master-Branche gesperrt, stattdessen soll ihr für jede Aufgabe
einen eigenen Branch erstellen und dort die Aufgabe lösen.
Der grobe Zusammenhang wird in der Tafelübung und den Übungsvideos erklärt und soll ihr
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 mit ZIP und der Einhaltung aller
Corona-Bestimmungen oder Remote-Mittels per Programming arbeiten.
Werkzeuge gibt es viele dafür, wir haben euch dazu ein paar 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 unsere Test-Hardware 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 Master
Branch merchen.
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 überlegentlich 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 Waffelermeldung auf die E-Mailing-Liste e4stubs.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 Plagiade 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 Repost 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 im Präsenz vor Ort oder virtuell mittels
BigBlueButton.