input/output management -...
TRANSCRIPT
1
Januar 19ZHAW, BSy, M. Thaler1
I/O Managment und Software
Input/Output ManagementTanenbaum Kap. 5
Stallings Kap. 11
Glatz Kap. 6
2
Januar 19ZHAW, BSy, M. Thaler2
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
3
Januar 19ZHAW, BSy, M. Thaler3
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 Linux Modul/Treiber-System erklären
• das Windows I/O-System erklären
4
Januar 19ZHAW, BSy, M. Thaler4
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)
• 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
• Hardware, die an Computer angeschlossen ist
• z.B. Disk, Drucker, etc.
� logisch
• eine Softwarekonponente, die über die Geräteschnittstelle angesprochen wird (meist Filesystem)
• z.B. Unix/Linux: /dev/null, /proc Filesystem mit Systeminformation, etc.
5
Januar 19ZHAW, BSy, M. Thaler5
Um was geht es: z.B. PC-Architektur
monitor processor
bridge/memorycontroller
IDE disk controllerexpansion bus
interface keyboard
serialport
parallelport
cache
memory
disk
disk
disk
disk
disk
disk
disk
disk
PCI bus
expansion bus
SCSI controllergraphicscontroller
AGP
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.
6
Januar 19ZHAW, BSy, M. Thaler6
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
IDE Controller Disk Controller
Disk System
7
Januar 19ZHAW, BSy, M. Thaler7
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)
• Kontrollregister für
- Konfiguration und Steuerung
• Datenregister für
- Datenpufferung und Datenaustausch
8
Januar 19ZHAW, BSy, M. Thaler8
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
• 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
� Daten können meist nicht an der Zieldestination gespeichert werden
• Vorverarbeitung
• Echtzeitprobleme
- Sharing
� Verwaltung und Organisation gemeinsam nutzbaren und dediziertenRessouren
9
Januar 19ZHAW, BSy, M. Thaler9
I/O-Architektur
device driverdevice driver
Ker
nel
BS I/O-Interfaceharwareunabhängig
APIgeräteunabhängig
Use
rH
ardw
are
HW I/O-Interface
user Process
kernel I/O subsystem
device driver
device
device controller
device driver
device
device controller
user Process
HW-Interface
• Architektur: Schichtenmodell
• Wichtigste Komponente: DeviceDevice DriversDrivers
- 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 Resource betrachtet, Schnittstelle zu Benutzerprozess (API): read/write, put/get
• Device I/O
- angeforderte Operationen in entsprechende Sequenzen von I/O Instruktionen umwandeln, Buffering
• Scheduling und Control
- steuert Ablauf der Interaktion zwischen Gerät und Software, Interrupt Handling, I/O Status, etc.
• API
- bei den meisten Betriebssystemen und Geräten
� Zugriff wie auf Files: open(), read(), write(), close()
10
Januar 19ZHAW, BSy, M. Thaler10
� Wichtige Services des Kernels
• I/O-Scheduling
• Buffering
• Caching, Spooling, Reservation
• Fehlerbehandlung
� Z.B. Buffering
Das Kernel I/O-Subsystem
Betriebsystem Benutzerprozess
I/O Gerät
I/O Gerät
• 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
� zwischen zwei Geräten
� zwischen Gerät und Kernel und Applikation
- Gründe
� verschiedene Übertragungsgeschwindigkeiten und Blockgrössen
� Prozesse können sind nicht aktiv oder sind ausgelagert
• Caching
- 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.
11
Januar 19ZHAW, BSy, M. Thaler11
Error Handling
� Fehler im Zusammenhang mit I/O vielfältig
• temporär z.B. überlastetes Netzwerk
• permanent 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/Linux hinterlegt in Variable errno einen 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 */
• 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
� testen of Files schon gelocked ist
� oder ob locking schief gelaufen ist
12
Januar 19ZHAW, BSy, M. Thaler12
I/O-Geräte: Charakteristiken
� Charakter (Byte) Stream vs. Block
• Stream
- Datenübertragung Byte um Byte, z.B. serielle Schnittstelle
- charakteristisches Verhalten: spontan erzeugter Input
• Block
- 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)
• Stream Geräte (Character)
- Zugriffsfunktionen
� put(), get()
• Block Geräte
- Zugriffsfunktionen
� read(), write(), seek()
- Variante: z.B. RAM-Disk
� RAM-Disk gleiches Verhalten gegenüber Anwendung, aber Zugriff auf Daten im Hauptspeicher
• Netzwerk Geräte
- unterscheiden sich wesentlich von Disks
� Adressierung und Performance
- Meist verwendete Schnittstelle: Sockets
� Win/NT, Unix, Java
� Zugriff auf Sockets über Filesystem
13
Januar 19ZHAW, BSy, M. Thaler13
I/O Geräte: Charakteristiken
Reaktionszeit
Datenmenge
Verzögerung
latency
transfer ratedelay
Geschwindigkeit
DiskCD-ROM
(GPU)
read write
readonlywriteonly
Richtung
Tape
Keyboard
dedicated
sharableSharing
Tape
Keyboardsynchronasynchron
Ablauf
ModemDisk
sequential
randomZugriffsmethode
TerminalDiskNetzwerk (sockets)
character (stream)
blocknetwork
Transfer-Modus
BeispielMöglichkeitenEigenschaft
• 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
14
Januar 19ZHAW, BSy, M. Thaler14
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)
15
Januar 19ZHAW, BSy, M. Thaler15
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.
• Unix und Linux I/O Architektur ähnlich
- relativ einfach zu verstehen
- relativ einfach zu programmieren
16
Januar 19ZHAW, BSy, M. Thaler16
Linux: I/O-Architektur
system call interface
file subsystem
buffer cache
character block
device drivers
hardware control
device
process control subsystem
schedulermemory
managementIPC
libraries
user programs
device device
user level
kernel level
hardware
17
Januar 19ZHAW, BSy, M. Thaler17
Linux: Ablauf Gerätezugriff
Benutzerprozess Betriebssystem(geräteunabhän.)
Treiber Controller mitI/O Gerät
I/O system call
driver call
I/O commands
interrupt
return from driver
return system call
continue/repeat
18
Januar 19ZHAW, BSy, M. Thaler18
Linux: Treiber vs. Modul
init_module() register_capability()
printk()
. . .
. . .
cleanup_module() unregister_capability()
KernelModule
insmodModul einfügen
capabilities[]
f1
f2
. . .
modulefunctions
function call
function call
function call
data pointer
rmmodModul entfernen
func
tion
poin
ter
• 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
19
Januar 19ZHAW, BSy, M. Thaler19
majornumber
drivername
fileoperations
file - operation - table
Linux: Modul und Device-Treiber
mknod /dev/MyDev c major minor register_chrdev (major, name, fops)
device files
/dev/tty0
. . .
/dev/MyDev
Character Device
modules
open()
close()
read()
write()
. . .
Hardware
"MyDriver"
MyDriver
0
...
128
129
...fd = open("/dev/MyDev", O_RDRW)write(fd, buffer, size)
•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
- verbindet die Treiberfunkionen (in einer Struktur abgelegt) mit dem entsprechenden Major Nummer Eintrag in der File Operation Tabelle
- Beispiel: register_chardev(127, "MyDriver", &myFileOps);
20
Januar 19ZHAW, BSy, M. Thaler20
Linux Treiber: File Operationen
/* using the tagged method, portable */
struct file_operations MyFops = {
open: MyOpen,release: MyRelease,
read: MyRead,
write: MyWrite,
};
struct mit 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);
}
Modul registrieren
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);
}
"open"
• 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);}
21
Januar 19ZHAW, BSy, M. Thaler21
kernel space user space
struct fpbuffer
im Treiber
buf
Anwender-prozess
copy_to_user
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)
• Anmerkung
- eine Problemstellung, die von allen Betriebssystemen gelöst werden muss
22
Januar 19ZHAW, BSy, M. Thaler22
Windows NT Architecture
• Alle auf Windows NT basierenden Varianten habe in etwa diese Struktur
23
Januar 19ZHAW, BSy, M. Thaler23
Das Windows Driver Model (WDM)
inf Dateien• Installationsdateien zu Treibern• scriptartige Befehle• alle notwendigen Informationen
•zum Treiber•zum entsprechenden Gerät
cat Dateien• enthalten digitale Signaturen• Verifikation, dass Treiber von MS
zertifiziert wurde
WDM - Windows Driver ModelWDF - Windows Driver Foundation
• Trieber unter Windows werden mit der WDF (Windows Driver Foundation) entwickelt
24
Januar 19ZHAW, BSy, M. Thaler24
� Zugriff auf Geräte
• über virtuelles Dateisystem
• I/O-Requests laufen in eigenem Thread
• Datenstrom von Bytes zwischen Anwendung und virtuellem Dateisystem
� I/O-Requests
• nicht alle Komponenten des I/O-Systems beteiligt
Gerätezugriff
API zu I/O-Diensten
I/O-Manager
Zugriff auf HAL
IO-Register und -Anschlüsse
Kernel-Modus TreiberTreiber-supportRoutinen
Anwendung
User Modus API
25
Januar 19ZHAW, BSy, M. Thaler25
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
Treiber
IRP Header
Stack-Einträge