4. Linux-Treiber. System Architektur

Transkript

1 4. Linux-Treiber Rubini, Alessandro: Linux Device Drivers, O Reilly, 2nd Edition, M. Beck, & al.: Linux Kernelprogrammierung Algorithmen & Strukturen der Version 2.4, Addison-Wesley, 6. Auflage, H. Herold: Linux Unix Systemprogrammierung, Addison-Wesley, 2. Auflage, R. Stevens: Advanced Programming in the Unix Environment, Addison-Wesley, System Architektur Unix Betriebssystem begonnen durch Linus Torvald. Open Source. Preemptives Multitasking. Prozesse und Threads (durch zusätzliche Bibliothek). Shared Libraries als Gegenstück zu den Windows DLLs. Monolithischer Kern mit Modulkonzept (auch dynamisch ladbar). Systemprogrammierung II, Winter 2002/03, P. Schulthess & M. Schöttner 95

2 Kern- Architektur: System-Call über Interrupt 0x80. Kern läuft im Ring-0 und Anwendungen im Ring-3. Getrennte Adressräume zwischen Kern (0-1GB) und User-Mode (1-4GB). Anwendungen System Libraries (libc) System Call Interface Modules I/O Related File Systems Networking Device Drivers Process Related Scheduler Memory Management IPC Architecture-Dependent Code Hardware Systemprogrammierung II, Winter 2002/03, P. Schulthess & M. Schöttner 96

3 4.1. Einbindung eines Treibers Statische Treiber Statisch mit dem Linux-Kern linken: Automatischer Symbol-Export (mydrvr_xvar), mydvr_init-routine wird beim System-Start gerufen, Treiber registriert sich selber beim Kern: int register_chrdev( unsigned int major, const char *name, struct file_operations *fops); Registrierung beim Kern: name nur für Meldungen, Treiber meldet sich mit einer Major-Nummer an, Dateioperationen in Vektor => do_basic_setup( ) register_chrdev(...) Kernel init do_basic_setup Device_setup tty_io #4 fops tty_init register_chrdev ( 4, &myfops) Systemprogrammierung II, Winter 2002/03, P. Schulthess & M. Schöttner 97

4 4.1.2 Dynamische Treiber in Modulen Treibermodule dynamisch nachladen: insmod /bt878/bin/frmgrbbr.o insmod erlaubt zur Laufzeit Module zu laden, init_module Routine wird aufgerufen, Modul registriert sich beim Kern. Modul entladen mit dem Befehl: rmod /bt878/bin/frmgrbbr cleanup_module Routine wird aufgerufen, Cleanup-Routine entfernt die Registrierung, Symboltabelle wird automatisch aufgeräumt. Symboltabelle im Kern (siehe auch /proc/ksyms): Grundlage für dynamisches Linken von Modulen, Enthält vorerst alle exportierten Symbole, static Namen jedoch nicht exportiert, Problem: Namenskollisionen, explizites Registrieren von Teilen der eigenen Symboltabelle mit register_symbtab( &chosen_few ) Superuser-Rechte notwendig für insmod & rmod. Systemprogrammierung II, Winter 2002/03, P. Schulthess & M. Schöttner 98

5 Versionskontrolle: Kompatibilität durch prüfen von Schnittstellen (Funktionen & Datentypen). Kern muss zunächst mit Versionsinformation übersetzt werden. Jeder exportierte Namen wird durch eine 32-Bit CRC erweitert. Beispiel: printk_r11ad48ba (11ad48ba ist CRC berechnet aus von printk genutzter Schnittstelle). Module müssen mit Schalter MODVERSIONS übersetzt werden! genksyms zum Export von Symbolen aus Modulen mit CRC. Gerätedateien im Verzeichnis /dev Gerätedateien z.b. /dev/hda1 für die IDE-Festplatte 1. Erscheinen als Datei für die User-Prozesse: Mit eigenem inode, Hier im Verzeichnis /dev/, Ohne Daten-Extent auf Platte, Im inode als Gerät vermerkt. Systemprogrammierung II, Winter 2002/03, P. Schulthess & M. Schöttner 99

6 Öffnen von Gerätedateien bzw. Treibern: int open(const char *pfadname, int opnflag, int mode) Als System Call aus dem User Kontext, Liefert Filedeskriptor oder Errorcode ( Err < 0 ), Filedeskriptor ist Index in inode-tabelle des Prozesses. Sowohl für echte Datei als auch für Gerät. int open(struct inode *i, struct file *fp) Korrespondierende Funktion im Treiber, inode: Major, Minor Nummer und Gerätetyp. fp: File-Pointer. Einrichten von Gerätedateien: mknod /dev/tty c 4 64 Name tty im Verz. /dev/, c : ist ein Character-Device, Neuer inode im Dateisystem, inode mit Feld vom Typ kdev_t = (4,64), Treibernummer 4 (Major Number). Gerätenummer 64 (Minor Number). Systemprogrammierung II, Winter 2002/03, P. Schulthess & M. Schöttner 100

7 Verbesserung durch devfs (ab Version ): Gerätedateien werden dynamisch erzeugt und entfernt. Gerätetreiber definiert Namen selbst Datei-Datenstrukturen FileDeskriptor als Integerzahl: Index in die Dateitabelle eines Prozesses, Standardinput, -output, -error (0,1,2). File bezieht sich auf einen inode. inode nimmt Bezug auf Treiber oder Diskfile. F_Deskr User Prozess files Kernel inodes Block-Cache Blocktreiber Treiber Treiber Treiber[i] Systemprogrammierung II, Winter 2002/03, P. Schulthess & M. Schöttner 101

8 Virtual File System Koexistenz mehrerer Dateisysteme: Reale Dateisysteme (... HPFS, Minix), /proc/ -Dateisystem, Gerätetreiber: Virtuelles Dateisystem Ext2 FAT xfs /proc/ Block-Cache Gerätetreiber Systemprogrammierung II, Winter 2002/03, P. Schulthess & M. Schöttner 102

9 Subsystem der /proc/-dateien Vorgespiegelte Dateien ohne persistente Speicherung. Informationen über Maschine, OS & Netz. /proc/ Pseudoverzeichnis: pci: gefundene PCI Devices stat: allgemeine Linux-Kern Statistik cpuinfo: inklusive CPU Designfehler devices: Character und Block Devices meminfo: Hauptspeicher, Cache, Swapspace... modules: geladene Module und Treiber /proc/sys/ Pseudoverzeichnis: fs/: Infos zu den Dateisystemen net/: Infos zu Netzwerksubsystemen vm/: Parameter der Speicherverwaltung kernel/: Infos zum Kern und zu Internetnamen /self/ Pseudoverzeichnis liefert Information über aktuelle Prozesse. Systemprogrammierung II, Winter 2002/03, P. Schulthess & M. Schöttner 103

10 4.4. Major & Minor Nummern inode enthält eine 32-Bit Zahl (früher nur 16-Bit): Major Number: obere 8-Bit bezeichen den Treiber, Minor Number: untere 8-Bit bezeichnen Device: Treiber kontrolliert evtl. mehrere Devices: mehrere Partitionen auf einer Festplatte, mehrere tty-leitungen. Dynamische Zuordnung von Major- & Minor-Nr., falls Registrierung mit major=0. Major Number Treiber Treiber Treiber Minor Number Device Device Device Systemprogrammierung II, Winter 2002/03, P. Schulthess & M. Schöttner 104

11 4.5. Operationen für Character-Devices Vektor für mögl. Operationen eines Character-Devices: Als Funktionsvariablen, NULL, falls nicht unterstützt, Evtl. Defaultimplementierungen: struct file_operations { loff_t ( *llseek) ( ), ssize_t ( *read) ( ), ssize_t ( *write) ( ), int ( *readdir) ( ), unsigned int ( *poll) ( ), int ( *ioctl) ( ), int ( *mmap) ( ), int ( *open) (struct inode*, struct file *), int ( *flush) ( ), int ( *release) ( ), int ( *fsync) ( ), int ( *fasync) ( ), int ( *check_media_change) ( ), int ( *revalidate) ( ), int ( *lock) ( ), }; Systemprogrammierung II, Winter 2002/03, P. Schulthess & M. Schöttner 105

12 Beispiel: Registrierung der File-Operationen #define KERNEL /* kernel code */ #define MODULE /* module */ int my_major=0; read_write_t my_read (struct inode *inode, struct file *filp, char *buf, count_t count) { } read_write_t my_write (struct inode *inode, struct file *filp, const char *buf, count_t count) { } struct file_operations my_fops = { NULL, /* lseek */ my_read, my_write, }; /* nothing more, fill with NULLs */ int init_module() { my_major = register_chrdev(my_major, "mydriver", &my_fops); return 0; } void cleanup_module() { unregister_chrdev(my_major, "mydriver"); } Systemprogrammierung II, Winter 2002/03, P. Schulthess & M. Schöttner 106

13 4.6. Nebenläufigkeit Jeder User-Prozess kann über INT 0x80 einen Systemaufruf absetzen und darauf warten. Preemption User Prozesse Koroutinen Kernel Space Eigener Adressraum pro User-Prozess. Preemption im User Space: Prozess wird in beliebigem Zeitpunkt suspendiert, Koroutinen im Kernel Space: Nur unterbrochen durch einen Hardware-Interrupt, Sonst allenfalls explizite Prozessumschaltung. Systemprogrammierung II, Winter 2002/03, P. Schulthess & M. Schöttner 107

14 User- und Kernel-Threads durch zusätzliche Bibliothek. Warteschlangen im Kernel: tq_scheduler: Tasks in dieser Queue werden immer ausgeführt, wenn der Scheduler aktiv wird. Laufen in der Umgebung des User-Prozesses, der schlafen gelegt wird. tq_timer: initiiert durch Timer (alle 10 ms), läuft im Interrupt. tq_immediate: Ausführung bei Rückkehr von Systemaufruf. Oder wenn der Scheduler aktiv wird. Tasks laufen als Bottom-Half. tq_disk: virtueller Speicher & Disk-Puffer Cache. Reserviert für internen Gebrauch. Bem.: zusätzlich können eigene Queues implementiert werden. Systemprogrammierung II, Winter 2002/03, P. Schulthess & M. Schöttner 108

15 4.7.1 Interrupt-Routinen 4.7. Ein-/Ausgabe Verarbeitung Treiber installiert seinen Interrupt: int request_irq ( unsigned int irq, void ( *handler ) ( int irq, void *dev_id, struct pt_regs *regs), unsigned long flags, const char * device, /* name für console */ void *dev_id ); /* optional */ Kernel prüft ob der IRQ verfügbar ist (result<0?)... handler als Interrupt Service Routine (ISR): Prozedurvariable mit Signatur, Evtl. ein Handler für mehr als eine IRQ Leitung, Alter Registerkontext. Flags: SA_SHIRQ bedeutet shared Interrupt., SA_INTERRUPT bedeutet fast handler. Systemprogrammierung II, Winter 2002/03, P. Schulthess & M. Schöttner 109

16 Shared Interrupts (SA_SHIRQ): Üblich am PCI-Bus, möglich am ISA-Bus, Interessenten für einen Interrupt werden verkettet, Kern ruft nacheinander alle Routinen zu einem Interrupt. dev_id optionaler Kontext für den Treiber. Beispiel: interrupt-basiertes Lesen struct wait_queue *my_queue; /* eigene Queue */ read_write_t my_read (struct inode *inode, struct file *filp, char *buf, count_t count) { if (nodataavail==true) { /* no data available? */ interruptible_sleep_on(&my_queue); /* we must sleep and wait */ } return count; /* number of read bytes */ } void myisr (int irq, void *dev_id, struct pt_regs *regs) { printk("my_driver: ISR running\n"); } wake_up_interruptible(&my_queue); /* is there a pending read? */ Systemprogrammierung II, Winter 2002/03, P. Schulthess & M. Schöttner 110

17 User process Kernel interruptible_sleep_on( ) Treiber ISR Device IRQ wake_up_interruptible( ) Systemprogrammierung II, Winter 2002/03, P. Schulthess & M. Schöttner 111

18 4.7.2 Bottom-Half Routinen Ziel: ISR möglichst kurz Lösung: Aufräumarbeiten außerhalb der ISR. Bottom-Half Routinen können unterbrochen werden und verbessern so die Anwortzeiten auf IRQs. Maximal 32 Bottom-Half Routinen werden gerufen beim Verlassen eines System Calls: return_from_ syscall #31 Bottom- Halfs in Treibern Kernelunterstützung für Bottom-Halfs: Registrierung: init_bh(int Nr, void (*bh_routine)(void)); Aktivierung: mark_bh(int Nr); Deregistrierung: remove_bh(int Nr); Systemprogrammierung II, Winter 2002/03, P. Schulthess & M. Schöttner 112

19 Beispiel: Bottom-Half struct tq_struct mybh_task; /* my bottom half task queue */ struct wait_queue *my_queue; /* waiting queue for pending readers */ void init() { mybh_task.routine = my_bottom_half; mybh_task.data = NULL; /* unused */ } void my_bh_interrupt(int irq, void *dev_id, struct pt_regs *regs) { queue_task_irq_off(&mybh_task, &tq_immediate); /* queue our bottom half */ mark_bh(immediate_bh); /* activate the queue */ } void my_bottom_half(void *unused) { wake_up_interruptible(&my_queue); /* wake up a pending reader */ } Tasklets bevorzugt, ab Linux 2.3.x: void my_do_tasklet (unsigned long); DECLARE_TASKLET (my_tasklet, my_do_tasklet, 0); void my_bh_interrupt(int irq, void *dev_id, struct pt_regs *regs) { tasklet_schedule(&my_tasklet); } Systemprogrammierung II, Winter 2002/03, P. Schulthess & M. Schöttner 113

20 4.7.3 Pufferzugriff Problem: Treiber darf nicht auf virtuellen User-Mode Speicher zugreifen: getrennte Prozeßadreßräume u. U. ist während der Abarbeitung des I/Os ein anderer Prozeß aktiv! Standard ist gepufferte E/A: Treiber kopiert Daten explizit um. copy_from_user (unsigned long to, unsigned long from, unsigned long len); copy_to_user (unsigned long to, unsigned long from, unsigned long len); Memory-Mapping alternativ: Treiber implementiert mmap. Vermeidet teueres Umkopieren. Puffer eines Treibers oder Speicher eines Gerätes in User-Adreßraum einblenden. Gut für Zugriff auf Grafikspeicher (z.b. für X-Server), aber weniger geeignet für eine serielle Schnittstelle. Systemprogrammierung II, Winter 2002/03, P. Schulthess & M. Schöttner 114

21 4.8.1 Hardware-Erkennung 4.8. Konfigurierung eines Treibers Bestimmung von E/A-Ports, IRQ und DMA: Automatisch im Treiber ( do_it_yourself ), Im Bootparameter für statisch gebundene Treiber, durch Programmzeilenparameter: insmod mydrvr c io_addr=0x400,0x408 irq=11 E/A-Adressen erkennen ( probing ): Verfügbarkeit prüfen mit check_region(port,len), Konfigurationsraum lesen für PCI-Geräte, Erkennung von ISA-Devices ist heikel, Auf ISA-Ports vorerst nur Lesen, Geräteisolierung mit Plug&Play. Erkennung zum Initialisierungszeitpunkt. Ressourcenallozierung so spät wie möglich. Systemprogrammierung II, Winter 2002/03, P. Schulthess & M. Schöttner 115

22 Eigenen Interrupt erkennen: Freischalten aller nicht allozierten Interrupts. Interrupt vom eigenen Gerät auslösen. Aufsammeln des Interrupts. freeirqs = probe_irq_on(); outb( mydevicecntrl, intonmask...); /* enable interrupts */ outb( mydevicedata, somebyte ); /* force interrupt */ udelay( 1000); /* wait for device */ outb( mydevicecntrl, intoffmask ); /* disable interrupts */ myirq = probe_irq_off( freeirqs ); /* get my interrupt */ Allozierung der Ressourcen Möglichst erst beim Öffnen des Treibers: mydrvr_open( inode, file) /* device open */ E/A-Ports reservieren (kein result): request_region( startaddr, len, Drvr77 ) Systemprogrammierung II, Winter 2002/03, P. Schulthess & M. Schöttner 116

23 Interrupt reservieren: success = request_irq ( Irq, Hdlr, Flags, ) DMA-Kanäle reservieren: success = request_dma( mychannel, Drvr77 ) Deinstallieren: release_region( ); free_irq( ); free_dma( ).. Systemprogrammierung II, Winter 2002/03, P. Schulthess & M. Schöttner 117

24 4.9. Block-Devices Registrierung und Operationen Registrierung: register_blkdev(major, name, fops) Operationen für Block Devices: struct file_operations my_fops = { NULL, /* lseek: default */ block_read, /* gegeben */ block_write, /* gegeben */ NULL, NULL, my_ioctl, /* mehrere vordef. Ctrl.-Codes, z.b. HDIO_GETGEO, */ NULL, my_open, my_release, block_fsync, /* gegeben (Puffer leeren) */ NULL, my_check_media_change, /* media change? */ my_revalidate /* disk change detected */ }; Systemprogrammierung II, Winter 2002/03, P. Schulthess & M. Schöttner 118

25 Programme schreiben und lesen in aus den vom Kern verwalteten Pufferbereichen: Block Cache, Directory Cache, inode Cache. Der Kern bietet eine Schnittstelle zum Transport von Blöcken an: block_read / block_write / block_fsync open / release, ioctl, check_change, revalidate. Die Synchronisierung zwischen Festplatte und Caches wird aus Effizienzgründen verzögert. Block-Devices können gemountet werden (z.b. mount /dev/hdb1 /win/c). Anforderungen vom Kern an den Treiber geschehen nicht über den File- Operations Vektor, sondern in einer blk_dev_struct: struct blk_dev_struct { void (*request_fn)(void); /* Request Funktion des Treibers */ struct request current_request ; /* aktueller Request */ } Request-Function liegt im Blocktreiber und interpretiert den aktuellen Request. Systemprogrammierung II, Winter 2002/03, P. Schulthess & M. Schöttner 119

26 4.9.2 Block-Device Datenstrukturen Array von Block Device Struktur mit zusätzl. Device Parameter Arrays für Block-, Sektorgröße,... Bei der Initialisierung wird u.a. die Request-Funktion eingetragen: blk_dev_struct[major].request_fn = my_request; Verkettete Requests: Kern reorganisiert evtl. Reihenfolge. Pro E/A-Operation ein Request. Enthält Cmd-Feld, Adressen zum lesen oder schreiben. blk_dev_struct[ major] minor Device parameter my_request requests s Systemprogrammierung II, Winter 2002/03, P. Schulthess & M. Schöttner 120

27 Gerüst einer Request-Funktion: void my_request(void) { while (1) { /* process all requests in queue */ INIT_REQUEST; /* macro checks for requests, returns if none */ switch(current->cmd) { /* CURRENT macro to access current req. */ case WRITE: memcpy(ptr, CURRENT->buffer, size); break; } end_request(1); /* complete block request (status=success) */ } } Systemprogrammierung II, Winter 2002/03, P. Schulthess & M. Schöttner 121

28 4.10. Network Devices Aufruf durch die Programme über Sockets. Multi-Protokollstack darüber: Mehrfache Netzwerkprotokolle, Multicast in SW oder HW, Pufferstrukturen hochreichen, an passende Protokollhandler. TCP BSD-Socket Interface INET-Sock Interface UDP... IP-Internet Protokoll ARP PLIP SLIP PPP PPP/ CAPI Ethernet 802.x Paralleler Port Serieller Port Serieller Port ISDN Karte Ethernet-Karte & dergl. Systemprogrammierung II, Winter 2002/03, P. Schulthess & M. Schöttner 122

29 Registrierung: Keine Major-Nummer, Treiber werden in globaler Liste verwaltet. Aufruf: register_netdev(struct net_device *dev); struct_net zunächst nur mit Name und Init-Routine. Kern ruft bei Registrierung die übergebene Init-Routine. Hier werden Ressourcen und Operationen in Struktur eintragen. Kern verwaltet Daten in Socket-Puffer struct sk_buff: Kern bietet Funktionen zum Zugriff auf Puffer: Puffer anlegen: alloc_skb(size, priority); Headergröße def.: skb_reserve(*skb, len); Daten am Ende anfügen: skb_put(...); Daten am Anfang anfügen: skb_push(...); Daten werden nur zwei Mal kopiert: Von User-Space nach Kernel-Space Und von Kernel-Space auf Ausgabegerät. Header... *socket *tcp_header *udp_header *ip_header *ethernet data Systemprogrammierung II, Winter 2002/03, P. Schulthess & M. Schöttner 123

30 Programmierschnittstelle für Sockets Systemaufruf socketcall : int sys_socketcall(int call, unsigned long *args); Funktionen entsprechend cmdparameter: int socket( int addrfamily, int type, int protocol) int bind( int socket, struct sockaddr *address, int addrlen) int listen( int socket, int backlog) int shutdown( int socket, int how)... Verbindungsorientiert (TCP): Server: socket, bind, listen, accept, recv Klient: socket, connect, send Verbindungslos (UDP): Server: socket, bind, recvfrom Klient: socket, sendto Systemprogrammierung II, Winter 2002/03, P. Schulthess & M. Schöttner 124