Friedrich-Alexander-Universität UnivisSuche FAU-Logo
Techn. Fakultšt Willkommen am Department Informatik FAU-Logo
Logo I4
Lehrstuhl für Informatik 4
Betriebssysteme
 
  Vorlesung
    - UnivIS-Infos
    - Inhalt
    - Folien
 
  Übungen
    - UnivIS-Infos
    - Inhalt
    - Mailingliste
    - Ergänzendes Material
    - Terminübersicht
    - Aufgaben
       * Umgebung
       * Typische Fehler
       * Aufgabe 1
          Dokumentation
       * Aufgabe 2
          Dokumentation
       * Aufgabe 3
          Dokumentation
       * Aufgabe 4
          Dokumentation
       * Aufgabe 5
          Dokumentation
       * Aufgabe 6
          Dokumentation
       * Aufgabe 7
          Dokumentation
 
  Evaluation
Department Informatik  >  Informatik 4  >  Lehre  >  WS 2010/11  >  Betriebssysteme  >  √úbungen  >  Aufgaben  >  Entwicklungsumgebung

Übungen zu BS - Entwicklungsumgebung

Für die Bearbeitung der Rechnerübungsaufgaben (und damit für die Entwicklung von OOStuBS und MPStuBS) 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 (QEMU) und zwei echte PCs (einen älteren Singlecore-Rechner für OOStuBS und einen modernen Multicore-Rechner für MPStuBS) 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 bzw. MPStuBS 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). Der x86-Emulator QEMU eignet 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 bzw. MPStuBS

  • oostubs.tar.gz aus /proj/i4bs/vorgaben/ in ein Verzeichnis entpacken (z. B. ~/oostubs):
    benjamin@faui48b:~> mkdir oostubs
    benjamin@faui48b:~> cd oostubs/
    benjamin@faui48b:~/oostubs> tar xfz /proj/i4bs/vorgaben/oostubs.tar.gz
  • Zu Aufgabe 1 gibt es je eine Vorgabe für OOStuBS (/proj/i4bs/vorgaben/vorgaben/vorgabe-full-oostubs-1.tar.gz) und MPStuBS (/proj/i4bs/vorgaben/vorgaben/vorgabe-full-mpstubs-1.tar.gz). Diese müssen nun im OOStuBS-Verzeichnis entpackt werden:
    benjamin@faui48b:~/oostubs> tar xfz /proj/i4bs/vorgaben/vorgabe-full-mpstubs-1.tar.gz
    Für alle weiteren Aufgaben gibt es nur noch eine gemeinsame Vorgabe (vorgabe-2.tar.gz usw.) für OOStuBS und MPStuBS. Diese müssen innerhalb dieses Verzeichnisses entpackt werden (die "Patches" enthalten alle für die jeweilige Aufgabe neuen notwendigen Dateien):
    benjamin@faui48b:~/oostubs/loesung> tar xfz /proj/i4bs/vorgaben/vorgabe-2.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 zugehörigen 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:
    benjamin@faui48b:~/oostubs/loesung> make
    DEP		dep/appl.d
    DEP		dep/startup.d
    DEP		dep/strbuf.d
    DEP		dep/o_stream.d
    DEP		dep/main.d
    DEP		dep/keyctrl.d
    DEP		dep/lapic.d
    DEP		dep/acpi.d
    DEP		dep/apicsystem.d
    DEP		dep/cgascr.d
    DEP		dep/guardian.d
    DEP		dep/cgastr.d
    ASM		build/_startup.o
    ASM		build/_setup_ap.o
    ASM		build/_io_port.o
    CXX		build/cgastr.o
    CXX		build/guardian.o
    CXX		build/cgascr.o
    CXX		build/apicsystem.o
    CXX		build/acpi.o
    CXX		build/lapic.o
    CXX		build/keyctrl.o
    CXX		build/main.o
    CXX		build/o_stream.o
    CXX		build/strbuf.o
    CXX		build/startup.o
    CXX		build/appl.o
    LD		build/system
    OBJCOPY		build/system.img
    BUILD		build/bootdisk.img
    BIOS-devicecode: 0x0
    Total T/H/S:     (80/2/18)
    Start T/H/S:     (0/0/1)
    
    Setup size is 1 sectors.
    System size is 11081 bytes.
    DD		build/bootdisk.qemu
    0+1 records in
    1+0 records out
    1474560 bytes (1.5 MB) copied, 0.054427 s, 27.1 MB/s
    

Testen und Debuggen von OOStuBS

  • Wenn ihr euer OOStuBS/MPStuBS mit dem Emulator (QEMU) testen wollt, dann ruft ihr einfach make qemu auf, was den Emulator mit dem Diskettenimage als virtueller eingelegter Diskette startet:
    wanja@faui48a:~/oostubs/loesung> make qemu
    Dabei wird QEMU so konfiguriert, dass er ein System mit zwei Prozessoren emuliert. Für die Entwicklung von OOStuBS stört dies nicht weiter, da dieses die zweite CPU einfach "links liegen" läßt.
  • Alternativ kann man auch den in QEMU integrierten 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 das Target qemu-gdb bereit:
    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.
    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
    Eine knappe Referenz der GDB-Funktionen könnt ihr hier finden. Wollt ihr detailierte Hinweise, wie ein bestimmter GDB-Befehl zu verwenden ist, so könnt ihr die in GDB eingebaute Hilfefunktion nutzen:
    (gdb) help <Befehlsname>
    Hinweis: Da durch den Emulator QEMU bei Verwendung des GDB-Stubs das Betriebssystem pausiert wird, darf man im GDB/DDD die Programmausführung nicht mit run neu anstoßen, sondern muss sie stattdessen mit continue fortführen.
  • Zum Testen auf den beiden Referenz-PCs im Rechnerübungsraum (01.155-N) gibt es das Makefiletarget netboot:
    wanja@faui48a:~/oostubs/loesung> make netboot
    Dieses kopiert euer gebautes System auf einen TFTP-Server, so dass die Test-PCs mit Hilfe des Netzwerkbootloaders PXELinux Zugriff darauf erhalten. Die Test-PCs booten beim Einschalten automatisch aus dem Netz. Im dann erscheinenden Boot-Menü müsst ihr dann nur noch den Eintrag mit euerem Login-Namen auswählen, um eueren OOStuBS/MPStuBS-Kernel zu booten.
  • Darüberhinaus gibt es noch die Möglichkeit eine Bootdiskette (1,44 MB, 3.5") mit einem OOStuBS/MPStuBS-Abbild zu erstellen. Damit könnt ihr, falls ihr zu Hause arbeiten wollt euer System auch auf richtigen Rechnern testen (sofern die noch über ein Diskettenlaufwerk verfügen. Zum Erstellen der Bootdiskette gibt es eine eigenes Makefile-Target bootdisk, welches das Diskettenimage auf die Diskette kopiert:
    wanja@faui07a:~/oostubs/loesung> make bootdisk
    Damit das funktioniert, muss eure Diskettenlaufwerk als /dev/fd0 eingehängt sein, oder ihr passt das Makefile entsprechend an.
  • Falls ihr kein Diskettenlaufwerk mehr habt, dann gibt es auch die Möglichkeit einen USB-Stick derart zu präparieren, dass man davon dann MPStuBS booten kann. Dazu müsst ihr wie folgt vorgehen (Im Folgenden wird angenommen, dass der USB-Stick als /dev/sdb im System vorhanden ist; natürlich müsst ihr das eurem System entsprechend anpassen. Wir übernehmen auch keine Haftung, wenn ihr euere Festplatte kaputt partitioniert, also passt genau auf, welches Gerät ihr verwendet):
    1. Zuerst bietet es sich an den USB-Stick wie eine Festplatte zu partitionieren. Das könnt ihr mit dem Partitionierwerkzeug euerer Wahl tun. Im Folgenden wird davon ausgegangen, dass eine Partition /dev/sdb1 exisitert, auf der dann die Daten des Bootloaders gespeichert werden.
    2. Falls noch nicht vorhanden müsst ihr ein Dateisystem auf dem USB-Stick anlegen:
      mkfs.vfat -F 32 /dev/sdb1
    3. Nun müsst ihr die gerade erstellte Partition mounten. Im Folgenden wird davon ausgegangen, dass die Partition unter /mount/point gemountet wurde.
    4. Nachdem die Partition eingehängt wurde, muss man nun noch GRUB installieren (root sollte man dafür schon sein, zumindest braucht man Schreibrechte für das "nackte" Device):
      grub-install --no-floppy --root-directory=/mount/point /dev/sdb
      Das sollte mit "Installation finished. No error reported." quittiert werden.
    5. Danach muss man das MPStuBS-ELF-Binary (build/system) auf den USB-Stick kopieren:
      cp meinmpstubs/build/system /mount/point/boot/mpstubs
    6. Jetzt muss man GRUB noch so konfigurieren, dass es das kopierte Binary bootet. Abhängig davon, ob ihr GRUB 1 oder GRUB 2 installiert habt, müsst ihr dazu eine zur GRUB-Version passende Konfigurationsdatei erstellen.
      Für GRUB 1 erstellt ihr auf dem USB-Stick die Datei /mount/point/boot/grub/menu.lst mit folgendem Inhalt:
      default 0
      timeout 30
      title = MPStuBS
      root (hd0,0)
      kernel /boot/mpstubs
      Solltet ihr schon GRUB 2 verwenden, so müsst ihr die Datei /mount/point/boot/grub/grub.cfg mit folgendem Inhalt erstellen:
      set default=0
      set timeout=30
      menuentry "MPStuBS" {
          set root=(hd0,1)
          multiboot (hd0,1)/boot/mpstubs
      }
    7. Wenn ihr jetzt von dem so präparierten USB-Stick bootet, dann sollte ein GRUB-Bootmenü erscheinen, in dem ihr dann MPStuBS auswählen könnt.

Quellcodeverwaltung in einem gemeinsamen SVN-Repository für die ganze Gruppe

Damit ihr einfacher in einer Gruppe zusammenarbeiten könnt, stellen wir für jede Gruppe ein SVN-Repository zur Verfügung, in dem jeder Gruppenteilnehmer einen eigenen Login besitzt.
Zuerst müsst ihr euer Repository einrichten. Dazu müsst ihr auf einem Rechner im CIP-Pool das script /proj/i4bs/bin/bsgroups ausführen. Dort gebt ihr eine Emailadresse an, an die dann nachher die Zugangsdaten für die Benutzer geschickt werden soll, und die Login-Namen für die weiteren Gruppenmitglieder (Derjenige, der das Script ausführt, wird automatisch als Gruppenmitglied eingetragen). Nach einiger Zeit (dies kann auch mal ein paar Stunden dauern) werden an die angegebene Mailadresse die Zugangsdaten für alle Benutzer geschickt. Nun könnt ihr das SVN verwenden, indem ihr das noch leere Repository mit der in der Antwortmail angegebenen URL auscheckt:
benjamin@faui48a:> svn co <URL>
Mit svn add FILES könnt ihr neue Dateien zur Versionsverwaltung hinzufügen; Mit svn commit werden die Änderungen ins Repository übernommen; Mit svn up spielt ihr von anderen gemachte Änderungen aus dem Respository in euere lokale Kopie ein.
  Impressum Stand: 2010-09-27 12:21   AG, WH, BO