TU Wien:Programmierung von Betriebssystemen UE (Huber)

Aus VoWi
Wechseln zu: Navigation, Suche

Daten[Bearbeiten]

Inhalt[Bearbeiten]

Es wird das Lehrbetriebsystem Pintos in 3 Aufgaben erweitert, dazu muss der Quellcode des Betriebsystems gelesen werden um die Erweiterungen einzubauen.

Ablauf[Bearbeiten]

Während des Semesters gibt es 3 Projekte, die in 3er-Teams gelöst werden. Zu jedem Projekt werden Testfälle bereitgestellt, die die Projekte auf Funktionalität und Robustheit testen. Jedes Projekt wird in myTI von *allen* Teammitgliedern als Archiv abgegeben, zusätzlich muss pro Projekt ein Design-Dokument abgegeben werden, in dem Änderungen dokumentiert und Fragen zur Implementierung beantwortet werden müssen. Vor jeder Deadline gibt es ein Analysegespräch mit der/dem zugewiesenen Tutor/in, welches jedoch nicht in die Beurteilung einfließt. Es empfiehlt sich, vor dem Analysegespräch bereits mit der Aufgabenstellung auseinandergesetzt bzw. diese implementiert (versucht) zu haben, um dann tatsächlich auch Hilfe in Anspruch nehmen zu können. Nach Project 1 und Project 2 findet ein Abgabegespräch statt, bei dem alle Teammitglieder detailliertes Wissen über die gesamte Implementierung vorweisen können müssen. Bei diesem Gespräch hat man den Quellcode nicht vor sich, muss aber dazu Fragen beantworten können. Man sollte sich daher den diff des Projekts (also auch besonders den Teil, den man nicht selbst gemacht hat), noch einmal ansehen und gut durchdenken.

Benötigte/Empfehlenswerte Vorkenntnisse[Bearbeiten]

TU Wien:Betriebssysteme VO (Puschner) und TU Wien:Betriebssysteme UE (Puschner) sind dringend zu empfehlen. Zumindestens sollte man gut C können.

Vortrag[Bearbeiten]

Es gibt nur eine Vorsprechung und eine einzige Vorlesung in der die Grundlagen von Pintos besprochen werden. Der Vortragsstil ist wirklich gut, man merkt das sich die Leute sehr gut auskennen. Es gibt zwar nur eine wirkliche Vorlesungseinheit, diese ist als Einführung jedoch sehr hilfreich und sollte besucht werden.

Andere Meinung: Kann ich so nicht widerspiegeln, Vortragsstil ist nicht sehr verständlich und sollte die Kenntnis wirklich so da sein (fast alles wird ja nur von Stanford übernommen) wird das nicht gut rübergebracht.

Übungen[Bearbeiten]

  • Project 0 (Intro): Alarm-Clock ohne Busy-Waiting implementieren, Beim Aufruf von Prozessen die Parameter auf den Stack legen.
  • Project 1 (Scheduling): Priority Scheduler mit Priority Donations
  • Project 2 (Virtual Memory Managment): Paging (ohne Swapping), Lazy Loading von Daten und Code Segment, Stack Growth, Memory Mapping von Dateien

Prüfung, Benotung[Bearbeiten]

Es gibt ein Abgabegespräch am Ende aller Abgaben. Dieses Gespräch und die erreichten Punkte bei den Abgaben ist Grundlage für die Note.

Es wird auf jeden im Gespräch eingegangen und eine individuelle Note gegeben. Es wird für die anderen Teammitglieder milder bewertet, wenn einer sich nur wenig oder gar nicht am Projekt beteiligt hat.

Dauer der Zeugnisausstellung[Bearbeiten]

Die Übungsnote wird sofort nach dem Präsentationsgespräch mündlich bekanntgegeben.

Zeitaufwand[Bearbeiten]

  • Die erste Aufgabe ist relativ schnell erledigt, ungefähr eine Woche sollte man sich dafür Zeit nehmen. Das Einlesen in den PintOS Code ist doch eher aufwändig.
  • Bei der zweiten Aufgabe frisst vor allem das Debuggen der Semaphoren viel Zeit, auf keinen Fall unterschätzen!
  • Die letzte Aufgabe ist relativ schön in Teilgebiete aufteilbar, innerhalb von 2-3 Wochen sollten die grundlegensten Sachen funktionieren (Lazy Loading der Code/Daten Segmente und Stack Growth).
  • Die LVA baut auf Betriebssysteme VO/UE auf und dementsprechend ist Vorwissen aus diesen LVAs schon sehr hilfreich. Ohne solide C-Kenntnisse wird es auch schwierig bzw. sehr aufwändig. Verschafft man sich beim Project0 einen guten Überblick über PintOS, kommt einem das auch bei den anderen Aufgaben zu gute. Insbesondere Debugging mit gdb sollten man sich so bald als möglich aneignen.

Unterlagen[Bearbeiten]

Tipps[Bearbeiten]

Gut dokumentierter Code kann Erklärungsnöten beim Präsentationsgespräch vorbeugen - wir mussten bspw. erklären was in einem (nicht dokumentierten), relativ unübersichtlichem Codesnippet vor sich geht.

Verbesserungsvorschläge / Kritik[Bearbeiten]

noch offen