Betriebssysteme 7.5 ECTS Prüfung 2021-03-08

• Prüfer: Volkmar und Chris
• Note: 1.0

Stimmung war an sich ganz entspannt.

Ich war mir manchmal nicht ganz sicher, ob ich das geantwortet habe, worauf er hinauswill, aber ich hatte das Gefühl er versucht die Antworten so zu verstehen, dass sie zu den Fragen passen.

Wo ich hing hat er versucht mit spezifischeren Fragen bis zur Antwort zur kommen.

Obacht: wir hatten Debugging nicht implementiert, er wollte trotzdem halbwegs genau wissen wie das funktioniert (ich sollte es mir dann während der Prüfung herleiten)

* Wann verwendet man denn Level-Triggered Interrupts?

Es gibt ja diese Unterscheidung zwischen Edge und Level Triggered. Level verwendet man, wenn es Daten gibt die man abholen muss

* Und wann verwendet man Edge Triggered?

Signalisieren ohne Daten zum Abholen. Habe als Beispiel Timer gesagt, er wollte noch ein zweites, hab IPI gesagt

* Wie läuft so ein Interrupt ab?

Ablauf aus Vorlesung erklärt mit wann wird welcher Zustand gesichert

* Wofür verwendet man denn IPIs?

Signalisieren zwischen Prozessoren. Zum Beispiel Idle Kerne aufwecken wenn neue Prozesse verfügbar sind oder Signale zustellen.

* Sagen wir, wir haben P() gemacht und uns mit Scheduler::block schlafen gelegt. Wie funktioniert das jetzt wenn jemand V() sagt (was ist da der Ablauf)

- Schauen ob der Zähler > 0
- Wenn ja Thread aus der Queue nehmen und an Scheduler::wakeup geben
- Scheduler::wakeup packt ihn in die Ready List und benachrichtigt die anderen Kerne dass sie neu schedulen sollen

* Es gibt ja noch spurious interrups, was ist denn das?

Interrupt muss nicht zwingend melden, dass neue Daten verfügbar, zum Beispiel kann kosmische Strahlung die Interruptleitung hochziehen. Da muss man robust programmieren

* Das wär jetzt ein Hardwarefehler, kann das denn auch wegen Software passieren?

Da gab es ein bisschen hin und her weil ich auf dem Schlauch stand. Er wollte auf folgenden Ablauf hinaus

1. Anwender macht cli()
2. Interrupt kommt, wird gepuffert
3. Anwender holt selber Daten von der Tastatur
4. Anwender macht sti()
5. Interrupthandler läuft aber hat keine Daten zum abholen

* Was sind denn Treiberklassen?

Man möchte ne möglichst einheitliche Schnittstelle weil das ist gut. Sowas wie read/write passt eventuell nicht auf alle Geräte z.B GPU, deshalb Schnittstellen pro Klasse

* Hast du Beispiele für Treiberklassen

Hab Zeichenorientiert (z.B serielle Schnittstelle), blockorientiert und Grafikkarte gesagt

* Da gibts noch ein mehr aber passt so. Wieso ist eine einheitliche Schnittstelle denn gut?

Macht es für die Anwender leichter und ist im BS schöner zu implementieren.
Gerätespezifische Schnittstellen würden perfekt zum Gerät zum passen aber man müsste das BS jedes Mal anpassen.
Stattdessen hat man lieber sowas wie auf Linux wo man Treiber registrieren kann indem man ein struct von Funktionspointer übergibt.
Das ist simpel und wäre sonst nicht möglichst

* Ein weiterer Vorteil ist ja dass man die Treiber wiederverwenden kann. Wie sieht das aus?

Man kann die Treiber ja stapeln. Ein Treiber verwendet dann nach unten einen anderen Treiber, damit kann man sich virtuelle Geräte bauen

* Hast du ein Beispiel?

Hab RAID erwähnt, der RAID Treiber verwendet nach unten die Festplatte

* Noch eins

Hab Dateisysteme erwähnt (nach oben: Dateischnittstelle, nach unten: Platte).
Ist ein bisschen anders als bei anderen Stacks aber im Prinzip kann man das sagen

* Kann man sich drüber streiten ob Dateisysteme Treiber sind aber kann man schon sagen * Was mag der Treiber nach unten?

Ports, Interrupts, Epiloge anfordern, kurz Infrastruktur

* Wie kann man seinen Treiber debuggen

- printf (hab wegen dem Linux-Bezug kprint gesagt), verändert halt das zeitliche Verhalten was für Race Conditions doof ist
- Debugging. Hier wollte er ziemlich genau wissen wie das funktioniert. Haben die GDB Stub Aufgabe nicht gemacht, deshalb wusste ich das nicht genau, habs mir hergeleitet:
Der Interrupthandler beim Debuggen sichert sämtliche Register, dann kann man da direkt drauf zugreifen
Es gibt das GDB Frontend und den Stub, die kommunizieren per Remote Serial Protocol mit so Befehlen wie gib mir die Register aus

* Der Name ist egal, wie funktioniert das jetzt wenn das Programm in Endlosschleife ist

Man schickt was über die serielle Schnittstelle, das interrupted und dann kommuniziert man mit dem Stub im Interrupthandler

* Microsoft sagt ja oft Windows ist nur instabil wegen den Treibern, was könnten die denn da machen?

Mikrokernarchitektur, Treiber haben dann nicht mehr volle Rechte und können das System nicht mehr zum Absturz bringen, der Kern benachrichtigt Treiber per Interrupts per Nachricht

* Warum macht Microsoft das nicht?

Zu viel Aufwand

* Meh

IPC per Nachrichten ist langsamer

* Wieso?

Latenz und kopieren

* Kann man sich ja sparen

Wenn die gemeinsamen Speicher haben

* Genau, dann hat man aber nichts gewonnen weil sie nicht mehr isoliert sind

MMU und Speicherschutz regeln

* Wieso ist das trotzdem langsamer?

Hier stand ich lange auf dem Schlauch

* Es gibt ja den Kontextwechsel zwischen Treiber und Kern

Man muss TLB und Cache invalidieren, das ist langsam

* Was gibts denn sonst noch

Bibliotheken, Exokernel, Virtualisierung

* Was ist Dualität?

Beide IPC Mechanismen sind gleichmächtig
Hab dann noch eine Mailbox Klasse auf Basis von gemeinsamen Speicher programmiert

* Wie kann man das auf mehrere Sender und Empfänger skalieren?

Mailboxen pro Emfpänger

* Aber geht das nicht kaputt wenn da zwei Leute in receive sind

Ne, da ist ja ein Mutex

* Was passiert da jetzt wenn zwischen avail.p() und dem mutex.lock() ein Kontextwechsel kommt?

Entweder der andere Faden ist noch vor dem avail.p(), dann muss er gegebenenfalls daran warten
Oder er kommt auch an avail.p() vorbei, das heißt dann auch, dass noch eine Nachricht für ihn verfügbar ist.
p() muss halt atomar sein