Für die Bearbeitung der Rechnerübungsaufgaben (und damit für die Entwicklung von OOStuBS) haben wir die benötigte Software unter /proj/i4bs/ bereitgestellt. Ihr könnt die Aufgaben natürlich auch zu Hause bearbeiten, wir empfehlen hierzu den Einsatz von Linux. Weiter unten finden sich einige Hinweise, wie ihr euren Linux-Rechner entsprechend konfigurieren könnt.
Achtung! Wer die Software bei sich zu Hause installieren möchte, trägt natürlich die volle Verantwortung für eventuelle Probleme. Fehlgeschlagene Installationen werden von uns auch nicht als Entschuldigung für verspätete Programmabgaben akzeptiert.
Da sich bei der Betriebssystementwicklung ab und zu auch Fehler einschleichen können, müsst ihr eure Lösungen testen, bevor ihr sie abgebt. Wir benutzen hierzu einen Emulator (Bochs bzw. QEMU)) und einen echten PC im Raum 01.155-N (Nebenraum des CIP-Pools im 1. Stock). Bei der Abgabe benutzen wir immer den echten PC, um eure Lösung zu kontrollieren. Ihr solltet deshalb immer auch mit dem echten PC testen, er ist die Referenzplattform!
Voraussetzungen zum Kompilieren von OOStuBS im CIP-Pool und zu Hause
Zum Kompilieren wird wie im Makefile vorgegeben g++ verwendet, zum Assemblieren des Startup-Codes und der hardwarenahen Teilprogramme der Netwide Assembler (nasm). Die x86-Emulatoren Bochs und QEMU eignen sich zum vorläufigen Testen und, durch einen eingebauten GDB-Stub, auch zum Debuggen mit dem GNU Debugger. Im CIP-Pool ist die entsprechende Umgebung vorhanden bzw. unter /proj/i4bs/ gemountet; wer das Ganze zu Hause machen will, muss sich die genannte Software entsprechend einrichten. Bei Problemen könnt ihr uns gerne fragen.
Kompilieren von OOStuBS
oostubs.tar.gz aus /proj/i4bs/vorgaben/ in ein Verzeichnis entpacken (z. B. ~/oostubs):
wanja@faui48a:~> mkdir oostubs
wanja@faui48a:~> cd oostubs
wanja@faui48a:~/oostubs> tar xzf /proj/i4bs/vorgaben/oostubs.tar.gz
Die Vorgaben (vorgabe1_patch.tar.gz usw.) müssen innerhalb dieses Verzeichnisses entpackt werden (die "Patches" enthalten alle für die jeweilige Aufgabe neuen notwendigen Dateien):
wanja@faui48a:~/oostubs/loesung> tar xzf /proj/i4bs/vorgaben/vorgabe1_patch.tar.gz
Alle Vorgaben, die ihr von uns erhaltet, lassen sich korrekt übersetzen, enthalten aber nur unvollständigen Code. Ihr müsst also Code vervollständigen. Die entsprechenden Klassen und Funktionen sind unter Aufgaben beschrieben, die zugehoerigen Dateien enthalten dann die entsprechenden Hinweise, wenn etwas vervollständigt werden muss.
Das eigentliche Kompilieren von OOStuBS erfolgt durch den Aufruf von make im Lösungsverzeichnis. Alle .cc- und .asm-Dateien im Lösungsverzeichnis werden daraufhin mit den entsprechenden Tools (Compiler bzw. Assembler) übersetzt. Mit Hilfe des build-Tools, das in oostubs.tar.gz enthalten ist, wird dann in build ein Diskettenimage generiert (bootdisk.img). Dieses Diskettenimage wiederum kann dann zum Testen im Emulator bzw. auf dem echten PC verwendet werden. Der Output des make-Prozesses sind in etwa folgendermaßen aus:
Wenn ihr euer OOStuBS mit dem Emulator (Bochs oder QEMU) testen wollt, dann ruft ihr einfach make bochs bzw. make qemu auf, was den jeweiligen Emulator mit dem Diskettenimage als virtueller eingelegter Diskette startet:
wanja@faui48a:~/oostubs/loesung> make bochs
wanja@faui48a:~/oostubs/loesung> make qemu
Für die Entwicklung der OOStuBS-Variante mit Mehrkernunterstützung (MPStuBS) können die Diskettenimages mit den Zielen bochs-smp und qemu-smp erzeugt werden. Dann werden jeweils Zweikern-Architekturen emuliert. Erste Erfahrungen deuten darauf hin, dass die Emulation von Mehrkernsystemen mit dem QEMU besser funktioniert als mit Bochs.
wanja@faui48a:~/oostubs/loesung> make bochs-smp
wanja@faui48a:~/oostubs/loesung> make qemu-smp
Alternativ kann man beide Emulatoren auch mit eingebautem GDB-Stub verwenden, um sich mit einem Debugger (gdb oder ddd) zu der Emulation zu verbinden. Auf diese Weise könnt ihr euren Betriebssystemcode bequem schrittweise ausführen, um den Grund etwaiger Abstürze oder ungewünschten Verhaltens herauszufinden. Dafür stellen wir im Makefile die Targets bochs-gdb und qemu-gdb bereit:
wanja@faui48a:~/oostubs/loesung> make bochs-gdb
wanja@faui48a:~/oostubs/loesung> make qemu-gdb
In dieser Konfiguration wartet der GDB-Stub im Emulator auf eine Verbindung an einer bestimmten Portnummer (von uns eingestellt auf die Prozess-ID des Skripts; falls der Port schon benutzt wird, einfach noch einmal das Skript ausführen, um eine neue Prozess-ID und damit auch eine neue Port-Nummer zu erhalten), über die sich ein gdb oder ddd mit dem Emulator verbinden kann, um das System zu debuggen. Beim gdb-Aufruf darf nicht das Diskettenimage als Parameter angegeben werden, sondern die Datei build/system, da nur sie die nötigen Debug-Informationen enthält. Der Debugger wird separart mit target remote localhost:Portnummer gestartet und mit dem GDB-Stub im Emulator verbunden. Die beiden Targets gdb und ddd in dem von uns bereitgestellten Makefile erledigen dies bereits für euch; zusätzlich führen sie noch ein break main und continue aus, so dass der Debugger bei main () startet.
wanja@faui48a:~/oostubs/loesung> make gdb
wanja@faui48a:~/oostubs/loesung> make ddd
Die folgende, eventuell auftretende Warnung des Debuggers, dass er beim Verbinden eine Antwort des GDB-Stubs nicht versteht, könnt ihr ignorieren:
warning: Remote failure reply: Eff
Zum Testen mit richtiger PC-Hardware (Referenzplattform!) müsst ihr eine Bootdiskette (1,44 MB, 3.5") erstellen. In unserem Rechnerübungsraum (01.155-N) stehen dazu diverse Linux-PCs bereit (faui07a-j), auf denen ihr euch einloggen könnt. Dort könnt ihr dann die Bootdiskette schreiben. Ein separater Rechner steht als Testrechner zur Verfügung. Bitte verwendet nur diesen Rechner zum Testen; die Linux-Rechner werden vom CIP-Pool administriert! Zu Hause könnt ihr natürlich auch euren eigenen PC oder Laptop verwenden. Zum Erstellen der Bootdiskette gibt es eine eigenes Makefile-Target bootdisk, welches das Diskettenimage auf die Diskette kopiert: