Betriebssysteme 7. Geräteverwaltung. Peter Altenbernd Geräteverwaltung Betriebssysteme WS 2010/11 Hochschule Darmstadt

Transkript

1 Betriebssysteme 7. Geräteverwaltung 1

2 Übersicht 1. Ziel des Kapitels 2. Motivation und Aufgaben 3. Einleitung 4. E/A-Schichtenmodell 5. E/A mit Plattenspeichern 6. Uhren 7. Terminals und Graphische Benutzeroberflächen (GUI) 8. Geräterverwaltung unter Linux 2

3 1. Ziel dieses Kapitels Dieser Teil beschreibt die Verwaltung von Ein/Ausgabe-Geräten (E/A-Geräte). Relevante Abschnitte im Buch [1] Kapitel 5 Abschnitt Abschnitt Abschnitt Zusätzlich Auszüge aus: [5] Jürgen Quade / Eva-Katharina Kunst Linux-Treiber entwickeln Eine systematische Einführung in Gerätetreiber für den Kernel 2.6 dpunkt.verlag, Juni 2004, ISBN

4 2. Motivation und Aufgaben Der Anwendungsentwickler will: eine einfache ( read, write ) einheitliche Schnittstelle, die von verschiedene Benutzer bzw. Anwendungen gleichzeitig & gemeinsam verwendet werden kann. Geräte müssen: in ihrer eigenen Sprache angesprochen werden zur richtigen Zeit, in der richtigen Reihenfolge angesprochen werden. Beispiel: Low-Level Festplatte E/A Das Anwendungsprogramm möchte eine Zeile von einer Datei lesen. Die Festplatte möchte wissen, zu welchem Zylinder, Spur und Sektor der Schreibkopf bewegt werden soll.. unter Berücksichtigung von fehlerhaften Sektoren, die ausgelagert wurden... es muss gewartet werden, bis der Schreibkopf bewegt wurde... das Lesen gestartet wurde, die Bits & Bytes von der Festplatte geholt wurden... die Header müssen entfernt, die Prüfsumme berechnet und verglichen werden... und so weiter. 4

5 2. Motivation und Aufgaben Eine der Hauptaufgaben eines Betriebssystems ist es, alle E/A Geräte (z.b. Tastatur, Bildschirm, Drucker, Festplatte etc.) zu überwachen und zu steuern. Dazu werden: Kommandos an die Geräte weitergeleitet Unterbrechungen abgefangen, Fehler behandelt eine einfache und einheitliche Schnittstelle bereitgestellt die gemeinsame Benutzung von Geräten ermöglicht 5

6 3. Einleitung 3.1 Geräte-Controller und -Klassen Quelle: [1] Das E/A-Gerät besteht aus dem Controller (elektrotechnische Komponente) und dem eigentlichen Gerät (mechanische und/oder elektrotechnische Komponente). Der Controller bekommt Befehle vom Betriebssystem und führt diese aus, z.b. Lesen von Daten eines Geräts. Dabei verwaltet der Controller oft gleich mehrere Geräte über eine Busverbindung. Die interne Steuerung eines Gerätes kann dabei ein ziemlich komplizierter Vorgang sein. Dennoch haben Geräte eine einfache Schnittstelle: weil ihr Funktionalität relativ gering ist und weil sie leicht anpassbar sein müssen, was durch standardisierte Bussysteme mit Spezialaufgaben erreicht wird. 6

7 3. Einleitung E/A-Geräte können grob in 2 Klassen eingeteilt werden: Als blockorientiertes Gerät gilt jedes Gerät, das nicht einzelne Zeichen nacheinander verarbeitet, sondern adressierbare Blöcke. Typische blockorientierte Geräte sind hier also: die Diskettenlaufwerke (fd0, fd1-- Major Number 2) und der Arbeitsspeicher (ram Major-Number 1), die Festplatten (hd* -- Major Number 3). Zeichenorientierte Geräte werden nicht blockweise angesteuert, sondern durch einzelne Bytes. Typischerweise handelt es sich hier um serielle oder parallele Schnittstellen, die Terminalleitungen (auch die der virtuellen Terminals) oder den Sound-Anschluss. 7

8 3. Einleitung 3.2 Kommunikation mit Geräten Jeder Controller besitzt einige Register, die für die Kommunikation mit dem Prozessor vorhanden sind. Durch das Schreiben in diese Kontrollregister kann das BS dem Gerät Befehle erteilen, z.b. Lesen oder Schreiben von Daten, Einschalten oder Ausschalten des Geräts, und Information vom Gerät holen, z.b. der aktuelle Zustand des Geräts Wird jedem Kontrollregister eine Port-Nummer zugewiesen, kann durch spezielle CPU-Anweisungen sehr einfach Daten in ein Kontrollregister geschrieben oder gelesen werden. Zusätzlich besitzen viele Geräte Datenpuffer, die das BS lesen oder beschreiben kann. Beispielsweise ist die Darstellung von Pixeln auf dem Bildschirm so realisiert, dass ein Datenpuffer (Videospeicher) beschrieben werden kann. 8

9 3. Einleitung Werden die Kontrollregister und Puffer in ein Speicherfenster im Adressraum des Hauptspeichers eingeblendet, spricht man von Memory-Mapped E/A. Zugriffe auf diese Speicherbereiche bewirken einen Transfer zum Controller. Es ergeben sich folgende Vorteile: Ports können i.a. nur mit Assembler-Befehlen angesteuert werden. Bei MM-E/A hingegen sind die Kontrollregister Variablen im Speicher, die mit den üblichen Methoden einer höheren Programmiersprache angesprochen werden können. Dies schließt Treiber-Programmierung mit ein. Der Schutz von E/A-Geräten ist einfacher, da lediglich die entsprechenden Stellen im Speicher entsprechend geschützt werden müssen. Nachteile: Für den betroffenen Speicherbereich darf kein Caching gemacht werden. Wird mit getrennten Geräte- und Speicher-Bussen gearbeitet, so können die Geräte die Adressen auf dem Speicher-Bus nicht sehen. 9

10 3. Einleitung 3.3 Direct Memory Access (DMA) Will eine Anwendung Daten z.b. von einer Festplatte lesen, so müssen diese in den Hauptspeicher transportiert werden. Übernimmt die CPU diese Aufgabe wird viel kostbare Rechenzeit für E/A verbraucht. Abhilfe schafft ein DMA-Controller, der diese Aufgabe übernimmt: Quelle: [1] 10

11 4. E/A Schichtenmodell Die SW zur Handhabung von E/A lässt sich in folgende Schichten aufteilen Quelle: [1] Die einzelnen Schichten werden im Folgenden genauer diskutiert. 11

12 4. E/A Schichtenmodell 4.1 Unterbrechungsroutinen (Interrupt Handler) Während ein Gerät eine ihm aufgetragene Aufgabe erledigt, geht die CPU anderen Tätigkeiten nach. Ist das Gerät fertig, erzeugt es einen Interrupt zur Benachrichtigung. Dies kann zum Teil recht komplexe Szenarios in Gang setzen. Das grobe Schema ist in der folgenden Abbildung dargestellt. Quelle: [1] 12

13 4. E/A Schichtenmodell Der Teil des Betriebsystems, der Interrupts und das oben genannte Szenario umsetzt, wird Interrupt Handler genannt. Ein Interrupt Handler umfasst somit alle Unterbrechungsroutinen und sollte die vielen notwendigen Details vom Rest des Systems möglichst verbergen. Ein Interrupt (z.b. durch Drücken einer Taste) kann dabei einen Prozesswechsel ausgelösen. Dann wird hardwareseitig (im Microcode) Folgendes getan: 1. Der Programmzähler und die Register des laufenden Prozesses werden auf den aktuellen Stack gelegt. 2. Die Unterbrechungsroutine wird aufgerufen (Pufferung der E/A, etc.). Alle weiteren Aktivitäten (d.h. Scheduling) erfolgen durch das Betriebssystem. 13

14 4. E/A Schichtenmodell 4.2 Gerätetreiber Da jeder Geräte-Controller anders ist, benötigt man dafür jeweils eine andere Systemverwaltung, um ihn zu steuern. Diese wird Treiber (Driver) genannt und stellt somit die Steuer-SW für ein Gerät dar. Jeder Controller-Hersteller muss einen Treiber für jeden Controller und für jedes Betriebssystem anbieten, das er unterstützen möchte. Es gibt also sehr viele unterschiedliche Treiber. Ein Gerätetreiber steuert eine bestimmte Art von Geräten an. So ist beispielsweise für die seriellen Schnittstellen ein Treiber - und nicht für jede einzelne serielle Schnittstelle ein eigener zuständig. Der wesentliche Ablauf ist bei vielen Treiber gleich: Der Treiber nimmt einen Befehl entgegen und schreibt ihn in ein Steuerregister des Geräts, um anschließend auf das Ergebnis zu warten. Ein recht praktikables Problem ist dabei, einen Treiber ohne großen Aufwand in das BS zu integrieren. Trotz dieser relativ einfachen Struktur ist die Treiber-Entwicklung sehr aufwendig, da viele Details beachtet werden müssen. Ein Treiber (d.h. oft fremder Code) läuft im Kern. Daher ist die Gefahr eines Systemabsturzes groß. 14

15 4. E/A Schichtenmodell Die Abbildung zeigt die logische Einordnung der Treiber in das Betriebssystem. Beispiel: Die Kommunikation zwischen Treiber und Controller läuft dabei über den Bus. Quelle: [1] 15

16 4. E/A Schichtenmodell 4.3 Geräte-unabhängige E/A SW A. Einheitliche Schnittstellen für Treiber Wäre z.b. jeder Tastaturtreiber völlig unterschiedlich, müsste das Betriebssystem für jede neue Tastatur neu angepasst werden. Deshalb gibt es für Geräteklassen einheitliche Schnittstellen. In Linux wird das physikalische Gerät auf eine oder mehrere so genannte (logische) Gerätedateien abgebildet. Damit eine Applikation einen Treiber identifizieren kann, ist dem symbolischen Gerätenamen (Treibernamen) eine so genannte Majornumber zugeordnet. Die Minornumber gibt i.a. an, das wievielte Gerät den Treiber benutzt. So stellen z.b. /dev/sda1 bis /dev/sda4 vier Partitionen auf einer Festplatte dar. B. Pufferung Zur Verringerung von Overhead werden verschiedene Puffer bereit gestellt: Die Unterbrechungsroutine legt alle ankommenden Zeichen in den Puffer und weckt den Prozess, wenn der Puffer voll ist. 16

17 4. E/A Schichtenmodell 4.4 E/A auf Benutzer-Ebene Nur ein relativ kleiner Teil der E/A-SW für den Zugriff auf E/A durch Anwendungsprogramme erfolgt durch Bibliotheksfunktionen, z. B. count = write(fd, buffer, nbytes); printf(stdout, The Square of %3d is %6d\n, i, i*i); Der Zugriff auf exklusiv zu nutzende Geräte (z. B. Drucker) wird durch Spooling ermöglicht. Dazu nimmt ein Hintergrundprozess (Dämon) Aufträge entgegen, die nacheinander abgearbeitet werden. Die Aufträge werden in einem Spooling-Verzeichnis, auf das nur der Dämon Zugriff hat, zwischen gelagert. 17

18 4. E/A Schichtenmodell Das Zusammenspiel der E/A-Ebenen ist in der folgenden Abbildung zusammen gefasst: Quelle: [1] 18

19 5. E/A mit Plattenspeichern Plattenspeicher umfassen Festplatten, Floppy-Laufwerke, CD Roms, CD-RW, DVD, DVD-RW, Memory Sticks. 5.1 Low-Level Formatierung Bei Festplatten kann der Schreiblesekopf einen bestimmten Bereich (Spur) lesen. Alle Spuren einer Position bilden einen Zylinder. Eine Spur wird in eine Anzahl Sektoren (fester Größe) unterteilt. Diese Aufteilung ist Teil der Low-Level Formatierung. Dagegen umfasst die High-Level Formatierung die Partitionierung, die Blockgröße und die Wahl des File-Systems. Es hat eine Umrechnung von Sektoren in die Blöcke des Dateisystems zu erfolgen. 19

20 5. E/A mit Plattenspeichern Bei Solid State Drives (Flash Memory) gibt es keine Zylinder und Spuren. Statt Sektoren gibt es Seiten (in Analogie zum Hauptspeicher). Auch hier hat eine Abbildung bzw. Umrechnung zwischen den Blöcken des Dateisystems und den Seiten des SSDs zu erfolgen. Dabei ist es oft so, dass die die Seiten größer als die Blöcke sind. 20

21 5. E/A mit Plattenspeichern 5.2 Zylinderversatz Bei einer Festplatte wird die Position des Sektors 0 in jeder Spur versetzt. Die Idee dahinter ist, dass die Platte mehrere Spuren mit einer einzigen Operation einlesen kann, da die Platte rotiert, während der Kopf von einer Spur zur nächsten bewegt wird. Beispiel für Zylinderversatz: 21

22 5. E/A mit Plattenspeichern 5.3 Planung der Kopfbewegungen (Festplatten-Scheduling) Die Zeit zum Finden eines bestimmten Block ergibt sich aus 1. der Suchzeit, bis zu der der Arm über der richtigen Spur steht 2. Rotationsverzögerungen, d. h. Finden des Sektors 3. Dauer der Datenübertragung Dabei dominiert die Suchzeit (1). Offensichtlich ist eine FCFS (First-Come FirstServed) Strategie keine gute Lösung. Daher verwalten viele Plattentreiber eine Tabelle oder verkettete Liste, in der die Zylinder-Nummern der noch auszuführenden Aufträge notiert werden. Beispiel: Folgende Anfragen treffen ein: 11, 1, 36, 16, 34, 9, 12 Wie viele Kopfbewegungen (als Anzahl Zylinder) ergeben sich mit FCFS ausgehend von 11? 22

23 5. E/A mit Plattenspeichern (a) Shortest-Seek First (SSF) Bei der SSF-Strategie wird die jeweils nächstliegende Position angesteuert: Wie viele Kopfbewegungen ergeben sich nun? Nachteil: Bei einer stark frequentierten Platte tendiert der Kopf dazu, sich die meiste Zeit in der Mitte aufzuhalten, so dass Zylinder am Rand benachteiligt werden. 23

24 5. E/A mit Plattenspeichern (b) Aufzug-Algorithmus Der Aufzug-(Elevator)-Algorithmus versucht, die konkurrierenden Ziele von Effizienz und Fairness in Einklang zu bringen. Die Strategie besteht daraus, solange nur in eine Richtung zu fahren, bis es dort keine Anfragen mehr gibt: Wie viele Kopfbewegungen ergeben sich nun? Im Allgemeinen ist der Aufzug-Algorithmus schlechter als SSF aber dafür fairer. 24

25 6. Uhren Uhren (Timer) in Computern werden für verschiedene Dinge gebraucht, besonders aber für Time-Sharing Systeme. Alles, was die Uhr-HW leistet, ist das Auslösen von Interupts in vorgegebenen Intervallen. Die Aufgaben eines Uhrtreibers besteht daraus: die reale Uhrzeit zu verwalten und Alarme zu behandeln Überwachung von Prozesslaufzeiten Profiling und Buchführung 25

26 7. Terminals und Graphische Benutzeroberflächen (GUI) 7.1 Terminals Auf Mainframes arbeit(et)en oft viele Benutzer von einer entfernten Arbeitsstation aus, wobei jede Station eine Tastatur und einen Monitor besitzt. Diese Geräte heißen aus historischen Gründen Terminals und können klassifiziert werden in: Verbindung (zu einem Mainframe) über eine serielle Schnittstelle (RS-232). Anzeigen eines PCs mit grafischer Benutzeroberfläche Netzwerk-Terminals Terminals sind zeichenorientiert. Die grundlegende Arbeit eines TastaturTreibers besteht darin, die Eingaben von der Tastatur zu sammeln und weiter zu reichen, d.h. in ASCII-Code zu übersetzen. Zum Beispiel bedeuten die Sequenzen: SHIFT drücken, A drücken, A loslassen, Shift loslassen und SHIFT drücken, A drücken, SHIFT loslassen, A loslassen beides ein großes A. 26

27 7. Terminals und Graphische Benutzeroberflächen (GUI) 7.2 GUI-Unterstützung GUIs können auf Benutzerebene laufen (Unix) oder im Betriebssystem selbst verankert sein (Windows). Untrennbar sind die Tastatur (s.o.) und Maus (o. Ä.) mit der GUI verbunden. Beide haben eigene Treiber und ggf. eigene Controller. Die Aufgabe des Maus-Treibers ist es, Bewegungen der Maus ( X, Y) mitzuteilen. Daraus muss die GUI die Position auf dem Bildschirm bestimmen. Außerdem werden Klicks bzw. Doppel- oder Dreifachklicks der 2 oder 3 vorhandenen Tasten übermittelt. 27

28 7. Terminals und Graphische Benutzeroberflächen (GUI) Grafikkarten, d.h. Anzeigegeräte der GUI enthalten einen Video-Ram, der einen Teil des Adressbereichs des Computers bildet und genau wie der Rest des Speichers adressiert wird. Bei der Pixeldarstellung werden im RGB (Red, Green, Blue) Modus 24 Bit je Pixel benötigt, 8 je Farbe. Je nach Leistungsfähigkeit der Karte ergeben sich unterschiedliche Auflösungen (z.b. 1024* 768). Hardware-Beschleunigungen der Grafikkarte implementieren Algorithmen aus dem Computer-Grafik-Bereich und unterstützen so beispielsweise das Problem zu erkennen, ob bei einer 3D-Animation ein Objekt vor einen anderen liegt oder nicht. 28

29 7. Terminals und Graphische Benutzeroberflächen (GUI) 7.3 Netzwerkterminals Netzwerkterminals werden dazu verwendet, einen entfernten Benutzer über ein Netzwerk hinweg mit einem Computer zu verbinden, auf dem er dann (fast) wie auf einem PC arbeiten kann. Es gibt zwei grundsätzlich verschiedene Ansätze: 1. Hochentwickelte Systeme Ein Beispiel dafür ist X-Window, welches der Unix-Welt entstammt, und in Linux auch für einen Single-User PC Verwendung findet. 2. Primitive Systeme beabsichtigen in erster Linie nur eine lokale Verbindung zu einem zentralen Rechner herzustellen. Hier wird das Endgerät möglichst einfach gehalten (praktisch nur Tastatur, Maus, Bildschirm) Thin Client, um Kosten zu sparen und die Administration zu vereinfachen. 29

30 7. Terminals und Graphische Benutzeroberflächen (GUI) Das X-Window System stellt eine Client-Server-Architektur dar. Die Ambition dabei ist, nur die absolut notwendigen Daten zu übertragen und trotzdem keine Einschränkungen bezüglich der Funktionalität in Kauf nehmen zu müssen. Dafür wurde ein eigenes Protokoll entwickelt, das X-Protokoll. Das X-Terminal ist ein PC, auf dem X-Window läuft. X-Clients befinden sich auf dem entfernten Rechner, die vom Server Aufträge bekommen, um bestimmte Dinge anzuzeigen. Der X-Server liegt nahe beim Benutzer und tut was man ihm sagt (wie alle Server) z. B. verarbeitete Maus- und Tastatur-Eingaben Ausführung von Anzeige-Befehlen des Clients Es gibt verschiedene Möglichkeiten, X-Window zu einem kompletten GUI auszubauen. Meistens wird bei Linux KDE oder Gnome benutzt. 30

31 8. Geräterverwaltung unter Linux 8.1 Linux Module und Treiber Linux bietet die Möglichkeit, einzelne Funktionalitäten in Form von Modulen auch nach Systemstart nachzuladen bzw. wieder aus dem System zu entfernen. Treiber sind solche Module. Um Module zu laden, die Liste der geladenen Module anzuzeigen und Module wieder zu entfernen stehen folgende Systemprogramme zur Verfügung: insmod, lsmod und rmmod. Außerdem können Module Metainformation, wie den Author, eine Beschreibung, die durch einen Treiber unterstützten Geräte und die Modul-Lizenz enthalten. Unter Linux lässt sich diese Metainformation mit dem Programm modinfo anzeigen. Status-Information über das Laden und Entfernen von Modulen wird in die Logdatei /var/log/messages geschrieben. 31

32 8. Geräterverwaltung unter Linux Da ein Modul kein abgeschlossenes Programm sondern Teil des Programms Betriebssystemkern ist, gibt es keine main-funktion. Stattdessen ruft der Loader (insmod), sobald sich der Modulcode im Speicher befindet, die Funktion init_module auf, bzw. vor dem Entladen wird die Funtkion cleanup_module aufgerufen. Es reicht aus, diese beiden Funktionen zu codieren, um unter Linux ein Modul zu erstellen. Damit eine Applikation einen Treiber identifizieren kann, ist dem symbolischen Gerätenamen (Treibernamen) die Majornumber zugeordnet. Da der Treiber bei der Initialisierung (in der Funktion init_module beim Aufruf der Funktion register_chardev) sich beim Betriebssystem ebenfalls unter einer Majornumber anmeldet, kann das Betriebssystem die Zuordnung zum Treiber durchführen. Treibercode: register_chardev(majorno, Hello-Driver,...) register_chardev(majorno, Hello-Driver,...) BS: $$ mknode mknode NameLogGeraet NameLogGeraet MajorNo MajorNo 32

33 8. Geräterverwaltung unter Linux 8.2 Treiberentwicklung unter Linux Ruft eine Anwendung einen Systemaufruf (z.b. read()) auf, reicht das BS diesen an den Treiber weiter. Um einen Treiber für Linux zu implementieren, muss folgenden Schnittstelle bedient werden: struct file_operations { struct file_operations { struct module *owner; struct module *owner; loff_t (*llseek) (struct file *, loff_t, int); loff_t (*llseek) (struct file *, loff_t, int); ssize_t (*read) (struct file *, char user *, size_t, loff_t *); ssize_t (*read) (struct file *, char user *, size_t, loff_t *); ssize_t (*aio_read) (struct kiocb *, char user *, size_t, loff_t); ssize_t (*aio_read) (struct kiocb *, char user *, size_t, loff_t); ssize_t (*write) (struct file *, const char user *, size_t, loff_t *); ssize_t (*write) (struct file *, const char user *, size_t, loff_t *); ssize_t (*aio_write) (struct kiocb *, const char user *, size_t, loff_t); ssize_t (*aio_write) (struct kiocb *, const char user *, size_t, loff_t); int (*readdir) (struct file *, void *, filldir_t); int (*readdir) (struct file *, void *, filldir_t); unsigned int (*poll) (struct file *, struct poll_table_struct *); unsigned int (*poll) (struct file *, struct poll_table_struct *); int (*ioctl) (struct inode *, struct file *, unsigned int, unsigned long); int (*ioctl) (struct inode *, struct file *, unsigned int, unsigned long); int (*mmap) (struct file *, struct vm_area_struct *); int (*mmap) (struct file *, struct vm_area_struct *); int (*open) (struct inode *, struct file *); int (*open) (struct inode *, struct file *); int (*flush) (struct file *); int (*flush) (struct file *); int (*release) (struct inode *, struct file *); int (*release) (struct inode *, struct file *); int (*fsync) (struct file *, struct dentry *, int datasync); int (*fsync) (struct file *, struct dentry *, int datasync); int (*aio_fsync) (struct kiocb *, int datasync); int (*aio_fsync) (struct kiocb *, int datasync); int (*fasync) (int, struct file *, int); int (*fasync) (int, struct file *, int); int (*lock) (struct file *, int, struct file_lock *); int (*lock) (struct file *, int, struct file_lock *); }; }; 33

34 8. Geräterverwaltung unter Linux Wird der Treiber geladen, wird zunächst die Treiber-Funktion init_module aufgerufen. Diese Funktion hat die Aufgabe, das zugehörige Gerät zu finden und schließlich den Treiber beim System anzumelden (register_chardev). Anhand des Parameters beim open-call erkennt das BS den von der Applikation gewünschten Treiber (über die Zuordnung zwischen dem symbolischen Gerätenamen und der zugehörigen Majornumber). Die Treiber-Funktion open wird durch das System angestoßen und überprüft, ob die Applikation auf das Gerät zugreifen darf oder nicht. Ist das der Fall, gibt die Treiberfunktion 0 zurück, ansonsten einen sinnvollen Fehlercode. Konnte das Gerät geöffnet werden, greift die Applikation über den beim Öffnen zurückgegebenen Filedeskriptor zu. Die an der Applikation übergebenen Argumente werden der zugehörigen Treiberfunktion übermittelt und dienen späteren read- und write-aufrufen. Schließt die Applikation das Gerät wieder, wird wiederum eine korrespondierende Funktion im Treiber aufgerufen: release. 34

35 8. Geräterverwaltung unter Linux Die Abbildung [5] verdeutlicht die verwendeten Komponenten und Abläufe. 35