I/O Managment und Software. Input/Output Management Tanenbaum Kap. 5 Stallings Kap. 11 Glatz Kap. 6

I/O Managment und Software Input/Output Management Tanenbaum Kap. 5 Stallings Kap. 11 Glatz Kap. 6 1 1

Inhalt Um was geht es? I/O-Hardware Geräte, Systeme, Schnittstellen, Controller Organisation und Architektur I/O-Software, Architektur Schichtenmodell, Scheduling, Buffering, Fehlerbehandlung Charakteristik von I/O-Geräten Block-, Stream- und Netzwerkgeräteugriff I/O-Architekturen Linux Modul und Treiber Konzept Windows 2 2

Lehrziele Sie können die grundlegende I/O-Architektur erklären und diskutieren die Konzepte des Linux Kernel I/O-Subsystems erklären Charakteristiken von I/O-Geräten aufzeigen und diskutieren das LinuxModul/Treiber-System erklären das Windows I/O-System erklären 3 3

Um was geht es? Computer zwei Hauptaufgaben "Processing" und I/O oft ist I/O Hauptaufgabe, z.b. - Daten-Aufnahme und -Speicherung - Web Browsing bzw. Networking Rolle des Betriebssystems mit I/O verwalten und steuern von I/O-Operationen und Geräten zu berücksichtigen - standardisierte Soft- und Hardwareschnittstellen USB, PCMCIA, PCI, etc. - Vielfalt von I/O-Geräten Geräte physikalisch (Hardware) und logisch (z.b. Sofwarefunktion) 4 Anmerkungen 1 - trotz Standardisierung hat jedes BS ein eigenes Treibermodell - die Softwareschnittestelle resp. das API ist meist ähnlich Schnittstelle meist ähnlich wie Filesystem Anmerkung 2 - Begriff "Gerät" physikalisch logisch Hardware, die an Computer angeschlossen ist z.b. Disk, Drucker, etc. eine Softwarekonponente, die über die Geräteschnittstelle angesprochen wird (meist Filesystem) z.b. Unix/Linux: /dev/null, /procfilesystemmit Systeminformation, etc. 4

Um was geht es: z.b. PC-Architektur disk disk monitor processor disk cache disk graphics controller AGP bridge/memory controller memory SCSI controller PCI bus IDE disk controller expansion bus interface keyboard disk disk expansion bus disk disk parallel port serial port 5 AGP: Accelerated Graphics Port Verschiedenste Peripheriebusse innerhalb eines PCs - AGP: accelerated graphics port stellt Graphik schnellen Zugriff auf Hauptspeicher zur Verfügung - PCI: peripheral component interconnect bus universeller Peripehrie Bus - SCSI: small computer system interface bis zu 15 Geräte pro Kanal (abhängig vom Standard) Disks, RAIDs, Scanner, etc. - IDE, E-IDE (enhanced) integrated drive electronics bis zu 2 Disks pro Controller folgt den ATA Standards Disks, CD, DVD, etc. - Expansion Bus USB: universal serial bus serieller Bus Peripheriegeräte aller Art PCMCIA: Personal Computer Memory Card International Assciation Cardbus(32-Bit), PCCard(16-Bit) Speicher, Modems, Netzwerkkarten, Buskarten, Disks, etc. Parallel und Serial Port etc. 5

I/O-Hardware Grosse Gerätevielfalt nur wenige Konzepte - wie Geräte an Computer angeschlossen werden - wie Software die Hardware steuert Anschluss der Geräte über Ports ein Gerät, Datenstrom, z.b. serielle Schnittstelle Busse mehrere Geräte, mehrere Drähte und ein Protokoll I/O-Controller Steuerelektronik für Port, Bus oder Gerät PCI Bus IDE Bus Disk System IDE Controller Disk Controller 6 6

I/O-Ports Typische Port Konfiguration: 4 Register Statusregister Kontrollregister DataIn DataOut Interaktion zwischen Prozess(or) und Geräten Polling busy wait(synchron) Interrupt Interrupt Handler(asynchron) DMA Datentransfer im Hintergrund (asynchron) 7 Kontrollregister für - Konfiguration und Steuerung Datenregister für - Datenpufferung und Datenaustausch 7

I/O-Software Ziele von I/O Software Geräteunabhängigkeit - Abstraktionen, z.b. Disk Drive einheitliche Namensgebung - z.b. Unix/Linux: "alles ein File" Fehlerbehandlung - möglichst nahe an HW asynchroner-/ synchroner I/O - Blocking System Calls bei asynchronem I/O Buffering - Vorverarbeitung, Echtzeitprobleme Sharing - gemeinsam genutzte Geräte, z.b. Disks 8 Ziele von I/O Software - Geräteunabhängigkeit Anwendersoftware soll unabhängig von den aktuell verwendeten Geräten laufen Abstraktion - einheitliche Namensgebung z.b. wie File ansprechen Unix/Linux: cat > /dev/tty - Fehlerbehandlung sollte möglichst nahe bei der Hardware geschehen viele Fehler sind nur "transient" - asynchroner (interrupt driven) / synchroner I/O (polling) auch asynchroner I/O soll für Anwender blockierend sein - Buffering - Sharing Daten können meist nicht an der Zieldestination gespeichert werden Vorverarbeitung Echtzeitprobleme Verwaltung und Organisation gemeinsam nutzbaren und dedizierten Ressouren 8

I/O-Architektur User user Process user Process API geräteunabhängig Kernel kernel I/O subsystem device driver device driver device driver device driver BS I/O-Interface harwareunabhängig HW I/O-Interface Hardware device controller device device controller device HW-Interface 9 Architektur: Schichtenmodell Wichtigste Komponente: Device Drivers - standardisierte Schnittstelle zum Kernel I/O-Subsystem - intern an Gerätedetails angepasst Initialisierung Lesen und Schreiben der Daten Keine vereinheitlichten Schnittstellen für Device Driver in Betriebssystemen - jedes Betriebssystem benötigt andere Treiber Logical I/O - Gerät als logische Resourcebetrachtet, Schnittstelle zu Benutzerprozess (API): read/write, put/get DeviceI/O - angeforderte Operationen in entsprechende Sequenzen von I/O Instruktionen umwandeln, Buffering Scheduling und Control API - steuert Ablauf der Interaktion zwischen Gerät und Software, InterruptHandling, I/O Status, etc. - bei den meisten Betriebssystemen und Geräten Zugriff wie auf Files: open(), read(), write(), close() 9

Das Kernel I/O-Subsystem Wichtige Services des Kernels I/O-Scheduling Buffering Caching, Spooling, Reservation Fehlerbehandlung Z.B. Buffering Betriebsystem Benutzerprozess I/O Gerät I/O Gerät 10 I/O-Scheduling - I/O-Anfragen von Anwendungen selten in optimaler Reihenfolge - BS ordnet Anfragen nach Optimierungskriterien Performance, Fairness, Wartezeit - Beispiel: Disk Scheduling Buffering - Buffer: Temporärspeicher für Datenaustausch, speichert Daten - Gründe Caching zwischen zwei Geräten zwischen Gerät und Kernel und Applikation verschiedene Übertragungsgeschwindigkeiten und Blockgrössen Prozesse können sind nicht aktiv oder sind ausgelagert - hält Kopie Daten für schnelleren Zugriff - z.b. Disk Cache Spooling - Spool: Speicher mit Daten für Geräte, die keine überlappenden Datenströme erlauben: z.b. Drucker - meist von Deamon verwaltet Reservation - Zugriffsreservation für nur exklusiv allozierbare Geräte - z.b. Tape, Frame-Grabber, Scanner, Soundkarte, etc. 10

Error Handling Fehler im Zusammenhang mit I/O vielfältig temporär permanent z.b. überlastetes Netzwerk z.b. defekter Disk Kontroller Wenn wichtige Hardwareeinheit defekt das BS kann sich mit grosser Wahrscheinlichkeit nicht erholen Systemaufrufe geben meist Information zum Erfolg des System Calls Unix/Linuxhinterlegt in Variable errnoeinen Fehlercode retval = fcntl(fd, F_SETLK, &lock) if (retval < 0) if ((errno == EACESS) (errno == EAGAIN)) return(-1); /* file is locked */ else perror("lock failed"); /* fatal error */ 11 Betriebssystem muss entsprechende Aktionen bei Hardware-Fehlern oder Defekten auslösen - z.b. Programm bei Speicherfehler stoppen - etc. Code aus Deamon Praktikum(Praktikum ProcThreads) - File locken testenof Files schongelockedist oder ob locking schief gelaufen ist 11

I/O-Geräte: Charakteristiken Charakter (Byte) Streamvs. Block Stream Block - Datenübertragung Byte um Byte, z.b. serielle Schnittstelle - charakteristisches Verhalten: spontan erzeugter Input - Datenübertragung als Block von Bytes, z.b. Disk - charakteristisches Verhalten: random access Netzwerkgeräte Zugriff meist über Sockets Sequentiell vs. Random Access Datenübertragung (Gerät) bestimmt Reihenfolge, z.b. RS-232 Anwendung bestimmt, welche Daten gelesen werden sollen, z.b. Diskblöcke (block device) 12 Stream Geräte (Character) - Zugriffsfunktionen Block Geräte put(), get() - Zugriffsfunktionen read(), write(), seek() - Variante: z.b. RAM-Disk Netzwerk Geräte RAM-Disk gleiches Verhalten gegenüber Anwendung, aber Zugriff auf Daten im Hauptspeicher - unterscheiden sich wesentlich von Disks Adressierung und Performance - Meist verwendete Schnittstelle: Sockets Win/NT, Unix, Java Zugriff auf Sockets über Filesystem 12

I/O Geräte: Charakteristiken Eigenschaft Transfer-Modus Zugriffsmethode Ablauf Sharing Richtung Geschwindigkeit 13 Möglichkeiten character(stream) block network sequential random synchron asynchron dedicated sharable read write readonly writeonly latency transfer rate delay Beispiel Terminal Disk Netzwerk (sockets) Modem Disk Tape Keyboard Tape Keyboard Disk CD-ROM (GPU) Reaktionszeit Datenmenge Verzögerung Transfermodus: Charakter (Byte) Stream vs. Block Datenübertragung Byte um Byte, z.b. serielle Schnittstelle Datenübertragung als Block von Bytes, z.b. Disk Netzwerkgeräte Zugriff meist über Sockets Sequentiell vs. Random Access - Datenübertragung in fester Reihenfolge, bestimmt durch das Gerät, z.b. RS-232 (stream device) - die Anwendung bestimmt, welche Daten gelesen werden sollen, z.b.diskblock (block device) Ablauf: synchron vs. asynchron - Gerätezugriff blockiert vs. Gerätezugriff blockiert nicht - kontinuierlicher Datenstrom vs. sporadische Daten I/O Richtung: read/write, read only, write only - z.b. Disk, z.b. CD-Rom, z.b..... Geschwindigkeit: Datenmenge Arbeitsgeschwindigkeit - einige wenige Bytes bis einige Gigabytes - Latenz, Transferrate, Verzögerung zwischen Operationen 13

Blocking vs. Non-Blocking I/O Physikalische Aktionen von I/O-Geräten i.d.r. asynchron nicht vorhersagbare, zeitvariable Ausführungszeiten Trotzdem meistens Blocking Systems Calls einfacher und sicherer zu handhaben Typische Non-Blocking Operationen API zu Maus und Keyboard (interaktive Applikationen) Video Interface - Daten vom Disk lesen, gleichzeitig dekomprimieren und auf Display darstellen - Realisierung: Buffering und Multithreading(Kernel Threads) 14 14

Unix/Linux-I/O Gerätetypen Block Geräte Stream Geräte Netzwerk Geräte Schnittstelle zu Geräten: Filesystem Geräte werden wie Files angesprochen Zugriffsfunktionen u.a. - open(), close() - read(), write() - etc. 15 Unix und Linux I/O Architektur ähnlich - relativ einfach zu verstehen - relativ einfach zu programmieren 15

Linux: I/O-Architektur user programs user level libraries kernel level system call interface file subsystem buffer cache scheduler process control subsystem memory management IPC character device drivers block hardware control hardware device device device 16 16

Linux: Ablauf Gerätezugriff Benutzerprozess Betriebssystem (geräteunabhän.) Treiber Controller mit I/O Gerät I/O system call driver call continue/ repeat I/O commands interrupt return from driver return system call 17 17

Linux: Treiber vs. Modul Module Kernel insmod Modul einfügen init_module() function call register_capability() capabilities[] data pointer f1 f2 function pointer... module functions function call printk()...... rmmod Modul entfernen cleanup_module() function call unregister_capability() 18 Linux - monolithischer Kernel - ladbare Module manuell on demand(automatisch) - Module sind "stapelbar" Geladenes Modul - Teil des Kernels - realisiert Kernel-Code Treiber - gehören zum Kernel - werden als Module realisiert 18

Linux: Modul und Device-Treiber Character Device mknod/dev/mydev c major minor register_chrdev(major, name, fops) /dev/tty0... /dev/mydev major number 0... 128 129 driver name MyDriver file operations "MyDriver" open() close() read() write()... Hardware device files... fd = open("/dev/mydev", O_RDRW) write(fd, buffer, size) file-operation-table modules 19 mknod - Shell Befehl - verbindet Device File mit Major Nummer - Major Nummern frei wählbar, dürfen aber nicht mehrfach belegt werden für Testzwecke stehen die Major Nummern 60..63, 120..127 und 240..254 zur Verfügung - Bespiel: mknod /dev/mydev c 127 0 register_chrdev - Registriert den Treiber im Betriebssystem - verbindetdie Treiberfunkionen(in einer Struktur abgelegt) mit dem entsprechenden Major Nummer Eintrag in der File Operation Tabelle - Beispiel: register_chardev(127, "MyDriver", &myfileops); 19

Linux Treiber: File Operationen /* using the tagged method, portable */ struct file_operations MyFops = { open: MyOpen, release: MyRelease, read: MyRead, write: MyWrite, }; structmit File Funktionen int init_module(void) { printk("hello from Module\n"); res = register_chrdev(my_major, "MyDriver", &MyFops); if (res < 0) printk("<1>cannot register MyDriver"); return(res); } int MyOpen(struct inode *inode, struct file *filep) { if (MOD_IN_USE!= 0) return(-1); /* already open */ MOD_INC_USE_COUNT; filep->private_data = &DatBuf; DatBuf.buffer = (void *)kmalloc(max_buf_len, GFP_KERNEL); return(0); } Modul registrieren "open" 20 Zugriff auf einen Linux Treiber Beispiel - Treiber /dev/mydef kann einen String speichern void main(void) { /* testing read and write */ int MyDev; int num_chars = 50; char vstr[200]; int Res = 0; char *str="dieser Text wird in den Buffer geschrieben"; strcpy(vstr, str); MyDev = open("/dev/mydev", O_RDWR); if (MyDev < 1) { perror("cannot open device: "); exit(-1); } Res = write(mydev, vstr, strlen(vstr)); strcpy(vstr, "@@@@ to disturb it @@@@"); printf("\n--> that's vstring: num %d, %s\n", Res, vstr); Res = read(mydev, vstr, num_chars); if (Res > 0) printf("--> got something: num %d, %s\n", Res, vstr); else perror("something's wrong"); Res = close(mydev); } 20

Datentransfer: Kernel und User Datenbufferung im Kernel Space Daten zwischen User Space und Kernel Space kopieren Problem: Anwenderprozess ist "swappable" - was, wenn Anwenderprozess nicht im Speicher steht? - Spezialfunktionen: copy_to_user(), copy_from_user() ssize_t read(struct file* fp, char* buf, size_t count, loff_t* unkn) struct fp buffer im Treiber copy_to_user buf Anwenderprozess kernel space user space 21 Anmerkung - eine Problemstellung, die von allen Betriebssystemen gelöst werden muss 21

Windows NT Architecture 22 Alle auf Windows NT basierenden Varianten habe in etwa diese Struktur 22

Das Windows Driver Model (WDM) cat Dateien enthalten digitale Signaturen Verifikation, dass Treiber von MS zertifiziert wurde inf Dateien Installationsdateien zu Treibern scriptartige Befehle alle notwendigen Informationen zum Treiber zum entsprechenden Gerät 23 WDM - Windows Driver Model WDF - Windows Driver Foundation Trieber unter Windows werden mit der WDF (Windows Driver Foundation) entwickelt 23

Gerätezugriff Anwendung Zugriff auf Geräte über virtuelles Dateisystem I/O-Requestslaufen in eigenem Thread Datenstrom von Bytes zwischen Anwendung und virtuellem Dateisystem I/O-Requests nicht alle Komponenten des I/O-Systems beteiligt Treibersupport Routinen User Modus API API zu I/O-Diensten I/O-Manager Kernel-Modus Treiber Zugriff auf HAL IO-Register und -Anschlüsse 24 24

Datenaustausch über IRPs (I/O Request Packet) I/O System arbeitet paketorientiert IRP: I/O Request Packet - enthält alle notwendigen Informationen IRP, besteht aus zwei Teilen fester Header - Art des Requests, Grösse - etc. 1 bzw. mehrere Stackeinträge - Funktionscode - Parameter - Zeiger auf Datenobjekt I/O-Systemdienste I/O-Manager IRP Header Stack-Einträge Treiber 25 25