Bei der Betriebssystemprogrammierung geht es noch mehr als in anderen Disziplinen um

Versuch und Irrtum.

Die Hardware ist nicht zwingend immer gut und eindeutig dokumentiert, für manche Geräte

ist es teilweise richtig schwer eine ordentliche Primärquelle zu finden.

Nicht selten finden sich im Internet gar widersprüchliche Informationen.

Aber selbst wenn wir über eine ausreichende Dokumentation wie bei dem Intel Manual verfügen,

so sind die paar tausend Seiten auch keine leichte Lektüre.

Wir werden oft erschlagen von historischen Überbleibseln und unterschiedlichen Varianten.

Eine einfache Lösung lautet oft Ausprobieren.

Aber wie können wir unser Betriebssystem testen?

Nun, die schnellste Variante ist eine virtuelle Maschine.

Beliebt sind für unseren Einsatzzweck besonders Box und QEMU.

Letzteres unterstützt mit KVM, der kernel-based virtual machine, auch CPU-Weiterungen wie Intel

VT und AMD V, womit eine schnelle und realitätsnahe Virtualisierung der CPU ermöglicht wird.

Das ist insbesondere für den Mehrkernbetrieb in NP-Stubs relevant, denn nur KVM bietet

echte Parallelität.

Bei der Software-Emulation hingegen wird die Ausführung der Kerne serialisiert, wodurch

viele Nebenläufigkeitsprobleme gar nicht auftreten.

Aber schlussendlich soll unser Betriebssystem auf echter Hardware laufen und hierfür haben

wir für euch einige Testrechner in dem Winzip gestellt.

Das sind i5 der ersten Generation, haben zwei physikalische Kerne mit Hyperthreading,

mp-stubsid somit vier Kerne.

Sie haben alle 8 GB RAM, 250 GB Festplatte, was wir aber nicht verwenden wollen, und eine

PS2-Tastatur sowie Maus.

Zudem sind sie über den COM1-Port, die Serial-Schnittstelle, mit einem Zip-Rechner verbunden.

Während früher erst das Betriebssystem auf Diskette kopiert, zum Testrechner getragen

und dort dann gebootet werden musste, und nicht selten haben Defekte Disketten dabei

die Probleme sogar unnötig vollkompliziert, setzen wir hier inzwischen auf eine bequemere

Variante.

Die Kerne werden über das Preboot-Execution-Environment aus einem Netzwerkverzeichnis geladen, dazu

seht ihr nach dem Boot ein Auswahlmenü, in welchem ihr euer Betriebssystem auswählen

könnt.

Während der Corona-Situation ist nun jedoch der Zutritt zum Winzip nicht so leicht möglich.

Aber auch dafür haben wir eine Lösung.

Ihr könnt den Fernzugriff 4VNC nutzen, um die Rechner zu bedienen und den Bildschirminhalt

der realen Hardware lokal zu sehen.

Entweder nutzt ihr dazu einen entsprechenden VNC-Client, ich kann hierfür Remina empfehlen,

oder ihr verwendet die Web-Oberfläche auf i4stubs.csv.de, welche auch einen Web-Client integriert hat.

Außerdem können über die Web-Oberfläche die Rechner neu gestartet werden.

Die Buttons on, off und reset senden dabei entsprechende Signale an den PC, während

Hardcycle die Vorschlaghammer-Methode ist und für 25 Sekunden den Strom physikalisch

trennt.

Bitte nur verwenden, wenn beispielsweise reset auch nach einigen Dutzend Sekunden nicht funktioniert.

Nun kann man damit natürlich hervorragend Kommilitonen ärgern, in denen man ihnen

beim Testen einfach den Strom trennt.

Bitte tut das nicht.

Wir setzen hier auf kollegiales Verhalten.

Solltet ihr auf einen Testrechner, der auf der Web-Oberfläche mit einem Status on versehen

ist, nicht per VNC zugreifen können, so wird dieser sehr wahrscheinlich von einem anderen

Studierenden verwendet.