input/output management -...

25
1 Januar 19 ZHAW, BSy, M. Thaler 1 I/O Managment und Software Input/Output Management Tanenbaum Kap. 5 Stallings Kap. 11 Glatz Kap. 6

Upload: vuongphuc

Post on 23-Aug-2019

230 views

Category:

Documents


0 download

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