Blockorientierte Geräte

Blockorientierte Geräte übertragen Daten jeweils in kompletten Blöcken. Dies gilt sowohl beim Lesen von diesem Gerät, als auch beim Schreiben auf selbiges. Typische Blockgrößen liegen zwischen 512 und 32 768 Byte. Jeder Datenblock ist direkt adressierbar.

Beispiele für blockorientierte Geräte sind:

• Festplatte
• CD- oder DVD-Laufwerk
• Bandlaufwerk

Beispiel

Eine Festplatte arbeite mit einer Blockgröße von 512 Byte. In Datenblock Nr. 723 soll das fünfte Byte geändert werden. Der folgende Ablauf ist dafür nötig:

• Lade Datenblock Nr. 723 von der Festplatte.
• Ändere das fünfte Byte wie gewünscht.
• Schreibe Datenblock Nr. 723 zurück auf die Festplatte.

Es können also immer nur komplette Datenblöcke ($\rightarrow$ in diesem Beispiel 512 Byte) gelesen oder geschrieben werden.

Der betreffende Datenblock wird direkt adressiert ($\rightarrow$ Nr. 723).

Schnittstelle für blockorientierte Geräte

Die Geräteverwaltung definiert üblicherweise eine Standardschnittstelle, welche die Treiber aller blockorientierten Geräte unterstützen müssen. Darin vorgesehen sind beispielsweise Funktionen für

• die Initialisierung des Geräts,
• das Lesen der Daten des adressierten Blocks vom Gerät,
• das Schreiben der Daten des adressierten Blocks zum Gerät, sowie
• die Behandlung eines vom Geräte-Controller ausgelösten Interrupts.

Diese Funktionen werden vom Gerätetreiber implementiert.

Zusammenarbeit von Treiber und Geräteverwaltung

Ist ein blockorientiertes Gerät am System angeschlossen, so wird sein Treiber (z.B. beim Systemstart) in den Hauptspeicher geladen. Der Treiber implementiert (u.a.) die Funktionen

• initDevice(),
• readBlock(),
• writeBlock(), sowie
• handleInterrupt().

Durch das Laden des Treibers in den Hauptspeicher steht ab diesem Moment fest, ab welcher Adresse im Hauptspeicher der ausführbare Code der genannten Funktionen beginnt. Dies gilt für jeden geladenen Treiber, also für jedes unterstützte Gerät.

Beispiel für Festplatte und Brenner

Beispiel

Zum Beispiel für die Festplatte

• ab Adresse 2 048   $\rightarrow$   initDevice()
• ab Adresse 2 560   $\rightarrow$   readBlock()
• ab Adresse 3 072   $\rightarrow$   writeBlock()
• ab Adresse 4 096   $\rightarrow$   handleInterrupt()

und für den DVD-Brenner

• ab Adresse 6 144   $\rightarrow$   initDevice()
• ab Adresse 7 168   $\rightarrow$   readBlock()
• ab Adresse 7 680   $\rightarrow$   writeBlock()
• ab Adresse 8 704   $\rightarrow$   handleInterrupt()

und so fort für jeden weiteren Treiber eines blockorientierten Geräts.

Die Geräteverwaltung wird über die Startadressen der implementierten Funktionen informiert und verwaltet diese entsprechend für alle unterstützten blockorientierten Geräte. Ab diesem Moment steht das Gerät für die Nutzung durch die Geräteverwaltung, durch das Betriebssystem und/oder einen Prozess zur Verfügung.

Ein Praxisbeispiel

Aus der Praxis

Eine etwas vereinfachte Darstellung für einen Prozess A, der Daten in eine (bereits geöffnete) Datei auf der Festplatte schreiben möchte:

• Der Prozess A verfügt über die zu schreibenden Daten.
• Der Prozess A informiert das Betriebssystem über seinen Schreibwunsch.
• Das Betriebssystem leitet den Schreibauftrag an die Geräteverwaltung weiter.
• Die Geräteverwaltung identifiziert die Festplatte als gewünschtes Gerät und sorgt dafür, dass Adresse 3 072 (siehe Beispiel oben) in den Programmzähler der CPU geladen wird.
• Die CPU beginnt mit der Ausführung des vom Treiber bereitgestellten Maschinencodes der writeBlock()-Funktion:
  • Der betreffende Block auf der Festplatte wird identifiziert (ggf. auch nacheinander mehrere Blöcke)
  • Die Daten des betreffenden Blocks werden von der Festplatte geladen.
  • Die geladenen Daten des Blocks werden entsprechend des Schreibwunsches des Prozesses A verändert.
  • Die veränderten Daten des Blocks werden zurück auf die Festplatte geschrieben.
  • Die Treiberfunktion ist nun erfolgreich abgearbeitet, es erfolgt ein Rücksprung zur Geräteverwaltung.
• Die Geräteverwaltung informiert das Betriebssystem über die erfolgreiche Abarbeitung des Schreibauftrags.
• Das Betriebssystem informiert den Prozess A über die erfolgreiche Ausführung seines Schreibwunsches.

Aufgabe 1

Aufgabe

 Aufg. 195: Systemaufruf im Praxisbeispiel

An welcher Stelle oder an welchen Stellen im Praxisbeispiel kommt es zu einem Systemaufruf?

Aufgabe 2

Aufgabe

 Aufg. 196: Prozesszustände im Praxisbeispiel

An welcher Stelle oder an welchen Stellen im Praxisbeispiel kommt es zu einem Zustandswechsel für den betreffenden Prozess A?

• Von welchem Zustand in welchen anderen Zustand erfolg der jeweilige Welchsel?
• Wer oder was führt den Zustandswechsel jeweils durch?
• Wo verwaltet das Betriebssystem die Information, in welchem Zustand sich der Prozess A gerade befindet?

Aufgabe 3

Aufgabe

 Aufg. 197: Interrupt im Praxisbeispiel

An welcher Stelle oder an welchen Stellen im Praxisbeispiel kommt es zu einem Interrupt?

Und welcher Prozess wird auf der CPU kurz vor bzw. kurz nach dem Interrupt ausgeführt?

Du kannst für deine Antwort ausgehen von:

• Außer Prozess A existiert noch mindestens ein weiterer Prozess B.
• Die Prozesse A und B sind voneinander unabhängig.
• Das Betriebssystem arbeitet mit Round Robin beim Scheduling.
• Es interessieren nur diejenigen Interrupts, an denen Prozess A "irgendwie" beteiligt ist. Alle sonstigen Interrupts, die für Prozess A keine Bedeutung haben, können im Rahmen dieser Aufgabe ignoriert werden.

Aufgabe 4

Aufgabe

 Aufg. 198: Just a simple assembler instruction

Im Praxisbeispiel ist zu lesen: Die Geräteverwaltung "sorgt dafür, dass Adresse 3 072 (...) in den Programmzähler der CPU geladen wird."

Welchen Assemblerbefehl nutzt die Geräteverwaltung für das Überschreiben des Wertes im Programmzähler der CPU?
Orientiere dich an der bereits bekannten simple machine language auf dieser Seite:
http://courses.cs.vt.edu/csonline/MachineArchitecture/Lessons/CPU/Lesson.html

Und was passiert dann auf der CPU direkt nachdem dieser Assemblerbefehl ausgeführt wurde? (In der nächsten Fetch-Phase.)

Aufgabe 5

Aufgabe

 Aufg. 199: CPU-Registerinhalte sichern im Praxisbeispiel

An welcher Stelle oder an welchen Stellen im Praxisbeispiel müssen Inhalte von CPU-Registern gesichert werden?

---

_{Diese Seite steht unter der Creative Commons Namensnennung 3.0 Unported Lizenz http://i.creativecommons.org/l/by/3.0/80x15.png}