Wie Testfälle implementieren (wie Information aus VM zu Hostsystem)?



  • Hallo,

    ich arbeite mit einer früheren Version von prettyOS (aus der Tutorialreihe aus dem 3ten Tutorial als gerade die Shell implementiert wurde, also Datei 91.rar).
    Ich arbeite außerdem unter Linux mit Bochs.

    Geplant ist, dass diese Version von prettyOS in einer Lehrveranstaltung bei unserer Universität benutzt wird (die aktuelle Version ist in meinen Augen zu umfangreich, außerdem ist schon zu viel Implementiert, deshalb würde ich diese Zwischenversion für ganz gut halten).

    Geplant sind z.B.:
    😉 Erweiterung der Syscalls (vielleicht Semaphoren?) Und dann mit Userprogrammen das Austesten
    😉 Implementierung eines anderen Schedulers
    usw. (falls ihr noch nette Ideen habt, könnt ihr die gerne posten)

    Allerdings sollten Testfälle natürlich automatisiert werden, allerdings weiß ich nicht so recht, wie ich das anstellen soll. Kann mir da jemand bisschen Input geben?
    Hätte mir vielleicht schon gedacht, dass ich eine normale Diskette nach Test.bin kopiere und diese als 2tes Diskettenlaufwerk Bochs mitgebe und dann einfach probiere, in prettyOS auf das Diskettenlaufwerk zu schreiben. Aber würde es da nicht eine einfachere Möglichkeit geben?

    Habe auch ein anderes OS getestet (pintOS) und dieses hat alles, was innerhalb der VM ausgegeben wurde ebenfalls auch auf die Bochs-Konsole ausgegeben. Wie kann man soetwas implementieren? Dann könnte ich nämlich alles auch bei der Console ausgeben und das könnte ich in eine Datei umlenken und diese parsen....

    lg,
    GoZu


  • Mod

    Geplant ist, dass diese Version von prettyOS in einer Lehrveranstaltung bei unserer Universität benutzt wird

    Es freut mich sehr, wenn das Projekt "PrettyOS" dazu beitragen kann, den Zugang zu dem interessanten, aber auch schwierigen Thema Betriebssystementwicklung vor allem in praktischer Hinsicht zu erleichten. Bitte machen Sie Werbung für unser privates open-source Projekt. Wir könnten noch einige begabte Entwickler mit ausreichend Biss brauchen. Aktuell arbeiten wir an dem Thema usb. EHCI und usb2.0 funktioniert bereits gut, die Grundlagen für OHCI und UHCI sind gelegt.

    Allerdings sollten Testfälle natürlich automatisiert werden

    Wir nutzen inzwischen die serielle Schnittstelle als Ausgabekanal auf eine Text-Datei. Ich empfehle als Emulation qemu, VBox und VMWare Player. Mit qemu kann man sehr einfach die serielle Schnittstelle verwenden, aktuelle Batchdatei:

    del serielleSchnittstelle1.txt
    del serielleSchnittstelle2.txt
    del serielleSchnittstelle3.txt
    del serielleSchnittstelle4.txt
    set QEMU_AUDIO_DRV=wav
    qemu.exe -boot a -fda G:\OSDev\PrettyOS\trunk\Source\FloppyImage.img -soundhw pcspk -net nic,model=rtl8139 -redir tcp:5023::23 -redir tcp:8080::80 -redir udp:8084::8084 -redir udp:8085::8085 -localtime -net user -net dump,file=netdump.pcap -serial file:serielleSchnittstelle1.txt -serial file:serielleSchnittstelle2.txt -serial file:serielleSchnittstelle3.txt -serial file:serielleSchnittstelle4.txt -usb -device piix4-usb-uhci -device pci-ohci -device pci-ohci

    Die serielle Schnittstelle lässt sich leicht nachrüsten:
    http://85.214.142.202/pretty/doc/serial_8h-source.html
    http://85.214.142.202/pretty/doc/serial_8c-source.html

    Die Geschichte von PrettyOS kann man sehr schön an diesem Thread nachvollziehen:
    http://www.c-plusplus.net/forum/236354

    Die aktuelle Version bietet inzwischen viele interessante Features, z.B. unser malloc mit String und die memleak-detection (#define _MEMLEAK_FIND_).

    Gerade die Themen syscalls und user-Programme sind dort viel besser ausgearbeitet. Netzwerk (wir haben ethernet, ip, arp, icmp, dhcp, udp, tcp) und usb2.0 sollten heute auch dabei sein. 🙂

    Ich unterstütze Sie sehr gerne bei der Umsetzung Ihres Projektes.

    Da man leicht den Überblick verliert über die im Internet angebotenen Ressourcen und Informationen, habe ich diese Übersicht angelegt: http://www.henkessoft.de/OS_Dev/OSDEV Ressourcen.html
    Vielleicht auch für Sie hilfreich.



  • Eigentlich wollte ich hier ja nicht kommentieren, aber Erhard hat mich ermuntert es doch zu tun. Nachdem ich ihn im IRC gefragt habe, ob ältere Pretty-OS-Versionen von den Konzepten her einigermaßen sauber sind, hat er geantwortet "Katastrophe ^^". Deswegen habe ich mich gefragt, ob für euch nicht auch das Tutorial-OS von der Lowlevel-Serie OS-Dev für Einsteiger interessant sein könnte (Code einer Beispielimplementierung gibt es hier).

    Die beiden Tutorials (und damit auch die zugehörigen Systeme) haben zwei völlig unterschiedliche Blickwinkel: Das Lowlevel-Tutorial ist geschrieben worden, nachdem schon einige Erfahrung da war, die weitergegeben werden soll. Das PrettyOS-Tutorial ist "live" während der Entwicklung von Erhards erstem OS-Projekt geschrieben worden. Daraus folgt, dass PrettyOS (vor allem in frühen Versionen) an einigen Stellen der Blick fürs große Ganze fehlt, dafür kann es beim Lowlevel-Tut andererseits sein, dass ein Erfahrener die Probleme eines Anfängers nicht mehr ganz so gut kennt.

    Je nachdem, was das Ziel sein soll, könnte also das eine oder das andere besser geeignet sein.

    Ach, und zur anderen Frage: Serielle Schnittstelle wäre auch meine Antwort gewesen. Es gibt auch noch den bochs-Debugport 0xe9, aber der ist offensichtlich nicht auf andere Emulatoren oder echte Hardware übertragbar.



  • Vielen Dank für die Antworten!

    Ja, ich habe mich schon mit mehreren OS beschäftigt und dabei auch die LowLevel-Tutorialreihe entdeckt.

    Also zurzeit habe ich mir schon potatoes (auf manchen PC's nicht lauffähig), pintOS (sehr umfangreich), das Project von LowLevel, OS/161, geekOS und eben prettyOS angesehen. (und noch ein paar andere kleinere, aber die nicht so genau).

    Das Problem ist immer: entweder nicht auf allen PC's lauffähig oder sehr schlecht Dokumentiert oder einfach zu kompliziert (also umfangreich).

    prettyOS in der jetzigen Version habe ich mir auch schon angesehen, das ist allerdings wieder um einiges umfangreicher als diese Zwischenversion. Außerdem sind schon viele Dinge implementiert (Systemcalls, besser Scheduler usw.).

    Die Entscheidung, ob nun prettyOS oder ein ganz anderes OS benutzt werden soll, werde schlussendlich nicht ich treffen, sondern die Studienassistenten (ich bin nur ein Student, der sich mal damit beschäftigen soll).
    Ziel soll es ja sein, dass die Studenten Spaß am OS developen haben und da ist es aus meiner Sicht her besser, nicht ein allzu kompliziertes OS ihnen vor die Nase zu setzen. (und bei prettyOS gibt es ja dieses wirklich tolle Tutorial (rießen thx an dieser Stelle) und darauf aufbauend wäre der Einstieg sicherlich nicht zu kompliziert, wodurch einige Studenten motiviert wären, weiter daran zu arbeiten).

    Ich werde mich die nächsten Tage einmal weiter damit beschäftigen und prettyOS unseren Studienassisten vorschlagen. Falls wir prettyOS verwenden, so werde ich mich sicherlich nochmals melden.

    lg und danke nocheinmal (für die Antworten sowie auch für das tolle Tutorial)


  • Mod

    Es ist klar, dass Rev. 91 nicht das Niveau des heute deutlich reiferen PrettyOS (aktuell: Rev. 1269) besitzt. Mein Tutorial ist allerdings in seiner Art unschlagbar, weil es durch die parallele Entstehung wirklich authentisch ist und den Blick des Einsteigers in die Materie abbildet. Solch eine Mischung aus "Logbuch" und Wissensvermittlung könnte ich heute nicht mehr schreiben. Das käme alles viel blutleerer daher, eben genau wie so viele wiki-Tutorials.

    Ich habe mich damals bewusst gegen das Konzept von taljeth entschieden, weil GRUB ("black box") verwendet wurde. Für mich war bottom-up entscheidend.

    Ich empfehle daher aus didaktischen Gründen unser PrettyOS, allerdings die aktuelle Version, weil man die Tutorials zum Einstieg findet und anschließend in einer lebendigen Community mit Chat und Forum daran weiter entwickeln kann. Man kann Fragen stellen und sich mit Ideen einbringen.

    Das Thema Memory Management wurde nachfolgend gut beschrieben (die aktuelle Variante des PMM und VMM entspricht dieser Beschreibung noch weitgehend, da wir damit hervorragend gefahren sind):
    http://www.c-plusplus.net/forum/261588-4

    PrettyOS bietet durch die #defines in os.h breite Einstellmöglichkeiten bezüglich Ausgaben. Seine "infobar" im unteren Konsolenbereich ist ideal geeignet für real-time Anzeigen (z.B. memleaks: malloc minus free oder floppy-Verhalten). ESC+h schiebt den heap-Inhalt auf die serielle Schnittstelle, ESC+p zeigt den physikalischen Speicher, strg+d die Ports und Disks, strg+c die Netzwerkverbindungen, strg+a den arp-cache. Man kann das leicht in ckernel.c erweitern. Die kernel-idle-loop kann im Sekundentakt mit Aufgaben versehen werden mittels Hinzufügen der entsprechenden Funktionen zur todolist, etc.

    Ziel soll es ja sein, dass die Studenten Spaß am OS developen haben

    Selbst kleine Spiele (immer an den "homo ludens" denken) sind vorhanden (ttt, arrow, pong). Zug und Schiff reizen sicher zu eigenen ASCII-Grafiken an.

    void serial_log(uint8_t com, const char* msg, ...) ist ideal dafür geeignet, schnelle Ausgaben in eine Textdatei durchzuführen. Gerade bei vm86 oder network ist dieses Feature von Vorteil. Hier ein Beispiel aus tcp.c:

    serial_log(SER_LOG_TCP,"\r\n seq = %u\tlen = %u\tseq.nxt: %u", inPacket->seq - connection->tcb.RCV.IRS, inPacket->ev->length, inPacket->seq - connection->tcb.RCV.IRS + inPacket->ev->length);
    

    MrX und ich stehen im chat (IRC-Server: irc.euirc.net, Channel: #PrettyOS) gerne für weitere Diskussionen und Erläuterungen zur Verfügung, gerne auch in englischer Sprache. Wir sind insbesondere an konstruktivem Feedback interessiert.

    Weitere Infos:
    http://www.henkessoft.de/OS_Dev/OS_Dev4.htm
    http://www.c-plusplus.net/forum/252232
    http://www.lowlevel.eu/wiki/PrettyOS
    http://de.software.wikia.com/wiki/PrettyOS



  • Geplant ist, dass diese Version von prettyOS in einer Lehrveranstaltung bei unserer Universität benutzt wird (die aktuelle Version ist in meinen Augen zu umfangreich, außerdem ist schon zu viel Implementiert, deshalb würde ich diese Zwischenversion für ganz gut halten).

    Aus didaktischer Sicht ist es - wie taljeth andeutet - nicht die beste Wahl, ein altes PrettyOS zu nutzen. Es ist wenig ausgereift und enthält Fehler und Designschwächen, die mittlerweile behoben sind. Ich denke nicht, dass es gut ist, die alte Version Studenten als Anschauungsobjekt zu geben.

    Geplant ist, dass diese Version von prettyOS in einer Lehrveranstaltung bei unserer Universität benutzt wird (die aktuelle Version ist in meinen Augen zu umfangreich, außerdem ist schon zu viel Implementiert, deshalb würde ich diese Zwischenversion für ganz gut halten).

    Vieles, was jetzt implementiert ist, ließe sich auch in ca. 10 Minuten wieder ausbauen für solche Zwecke, beispielsweise USB, VBE oder Netzwerk. Dafür hättest Du im aktuellen PrettyOS bereits einen Treiber für die serielle Schnittstelle und könntest von zahlreichen Fehlerbehebungen und Design- wie Performanceverbesserungen profitieren. Außerdem sind an einigen Stellen Treiberschnittstellen geschaffen worden, die für Eigenentwicklungen genutzt werden könnten (-> Gerätetreiber (Netzwerk, MSD), Dateisystemtreiber, Treiber für ausführbare Dateien))

    😉 Implementierung eines anderen Schedulers

    Der PrettyOS-Scheduler ist vor langer Zeit (aber auch erst lange nach dem Tutorial) neugeschrieben worden, auch wenn er nach dem gleichen Schema wie der alte (Round-Robin) arbeitet. Ich denke, dass es deutlich leichter ist, den neuen Scheduler zu ersetzen, als den alten, weil er stark mit anderen Programmteilen verknüpft war.

    (falls ihr noch nette Ideen habt, könnt ihr die gerne posten)

    Heap-Verwaltung. Davon könnten wir sogar profitieren, denn im Userspace haben wir bis heute keine brauchbare (nur placement).

    MrX und ich stehen im chat (IRC-Server: irc.euirc.net, Channel: #PrettyOS) gerne für weitere Diskussionen und Erläuterungen zur Verfügung, gerne auch in englischer Sprache

    Diskussionen auf Englisch überlasse ich Dir, Erhard. Ansonsten ist der Vorschlag allerdings gut: Schau mal im IRC vorbei.


Anmelden zum Antworten