Aufgabe 1 – Ein- und Ausgabe

Transkript zum Übungsvideo (Folien ).

Obwohl wir in der Betriebssystementwicklung sehr grundlegende Sachen machen, ist die Toolchain doch etwas länger als in vielen anderen Bereichen – und bedarf auch etwas Einarbeitung. Nach der ersten Aufgabe solltet ihr aber fit darin sein! Außerdem nutzen wir einige grundlegende C++ Eigenheiten. Sofern ihr bis jetzt nur in C oder Java programmiert habt, erlernt ihr in dieser Aufgabe alle für StuBS notwendigen Konzepte. Wer sich allerdings zu den C++ Kennern zählt: Versucht ein vernünftiges Maß anzuwenden und gut lesbaren Code zu produzieren, beispielsweise sind Templates für diese Aufgabe nicht notwendig, beziehungsweise in einigen Fällen sogar kontraproduktiv. Überlegt euch im Zweifelsfall den Einsatz sehr genau! Das Herz dieser Aufgabe ist natürlich die Programmierung der Ein- und Ausgabe. Diese werden wir auch noch in allen folgenden Aufgaben verwenden. Und sie gibt euch bereits einen guten Überblick über die verschiedenen Arten mit der Hardware zu kommunizieren. Sinnvollerweise fangt ihr natürlich erst mit der Programmierung der Ausgabe an, danach die Eingabe, und – sofern ihr Lust habt – könnt noch eine serielle Schnittstelle implementieren. Diese wird allerdings nicht gewertet, der CGA Textmode und Tastatur hingegen schon. Bitte legt auch entsprechend den Fokus.

Wenn ihr den StuBS Ordner öffnet, dann sieht das in etwa so aus: Wir haben fünf wichtige Quelltextordner, boot enthält den Startupcode, utils generische Helfer. In object liegt der der C++ Standardbibliothek nachempfundene OutputStream samt Stringbuffer, die ihr vielleicht schon für Aufgabe 0 implementiert habt und weiter verwenden könnt. Die Ansteuerung der Hardware wird in machine implementiert, hier müsst ihr den TextMode für die grundlegende Ausgabe implementieren, sowie die Erweiterung TextWindow, welche diesen in virtuelle Ausgabefenster unterteilt. Damit ihr nun einfach mit Streamoperatoren die Ausgabe in den Fenstern tätigen könnt, muss noch im Treiberverzeichnis device der TextStream erstellt werden, der dies mit dem OutputStream vereint. Alle Dateien, die ihr für diese Aufgabe anfassen müsst, sind rot umrandet. Die grün umrandeten Klassen und Namespaces sind für die optionale Aufgabe, der seriellen Schnittstelle. Insbesondere in machine sind noch Geräte vorhanden, welche nur kurz während der Initialisierung verwendet werden, wie zum Beispiel dem PIT – dem Programmable Interval Timer. Wir haben diese zwar dokumentiert, aber um den genauen Ablauf zu verstehen, muss man die entsprechenden Datenblätter gründlich wälzen. Wer Lust hat, darf sich das natürlich gerne genauer anschauen, aber es ist auch vollkommen in Ordnung, wenn man das stattdessen für schwarze Magie hält und vorerst nicht weiter verstehen will. Ein extremes Beispiel ist hierzu übrigens ACPI – das Advanced Configuration and Power Interface – welches derart kompliziert ist, dass selbst Linux und FreeBSD lieber die Referenzimplementierung ACPI Component Architecture von Intel verwenden.

Nach Aufgabe 6 wird euer StuBS in etwa so aussehen, vielleicht erkennt ja der eine oder andere die Struktur des sogenannten Betriebssystemburgers aus der Vorlesung wieder. Einen Teil der Dateien, insbesondere die langweiligen, geben wir euch mit jeder weiteren Aufgabe vor. Wir werden euch bei den Vorgaben allerdings nur neue Dateien geben, aber keine existierenden Dateien ändern, Mergekonflikte sollten also kein Problem sein. Zumindest so fern ihr euch auch an die von uns vorgegebenen Schnittstellen haltet, und nicht Dateien oder Ordner einfach umbenennt!

Wir werden eure per Merge Request gestellte Abgabe prüfen, euch Feedback geben und entweder akzeptieren oder – bei gravierenden Problemen – noch Ausbesserungen verlangen. Das ist notwendig, da ihr bis zum Semesterende an eurer eigenen Codebasis schrauben werdet. Entsprechend liegt das Hauptaugenmerk auch auf der vollständigen Umsetzung der Aufgabenstellung, erst wenn die Pflichtaufgaben implementiert, ausgiebig getestet, überarbeitet, nochmals getestet und dann noch ordentlich formatiert und kommentiert wurden, könnt ihr euch an die optionalen Aufgaben wagen. Dabei ist es vollkommen normal, dass man am Anfang der Aufgabe wie der Ochs vorm Berg steht. Das Verständnis kommt erst beim Lösen der Aufgabe, und noch mehr Verständnis bekommt man meist, wenn man zuerst auf dem Holzweg unterwegs war. Wir gehen nicht davon aus, dass irgendjemand die Aufgaben einfach so runterprogrammieren kann. Versucht die Aufgabenstellung genau zu lesen und entsprechend der empfohlenen Schritte zu implementieren. Die Übungsvideos oder Folien bei Bedarf nochmal zu Rate ziehen. Webseiten wie osdev und StackOverflow wälzen. Es ist auch ausdrücklich erlaubt, sich mit Kommilitonen über Probleme zu unterhalten, dafür sind auch der Chat via IRC und die Mailingliste da – allerdings keinesfalls Code zeigen oder weiterreichen, bei Plagiaten verstehen wir keinen Spaß. Wenn ihr massiv hängt, und auch nach längerem Überlegen und drüber schlafen nicht mehr weiter wisst, dann wendet euch bitte rechtzeitig an uns – wir versuchen euch dann weiterzuhelfen, vielleicht haben wir auch Unklarheiten bei den Aufgaben übersehen. Für jede Aufgabe haben wir zwei Wochen Bearbeitungszeit vorgesehen. Solltet ihr eine Krankheit haben, Prüfung oder beispielsweise die Abgabe der Bachelorarbeit, dann sagt uns bitte auch rechtzeitig Bescheid, und wir können dann eine Verlängerung geben. Aber versucht dies zu vermeiden, falls möglich, da die Aufgaben aufeinander aufbauen, und ihr somit immer weiter ins Hintertreffen kommt.