CS5460/6460: Operating Systems. Lecture 24: Device drivers. Anton Burtsev April, 2014

Similar documents
Virtual File System (VFS) Implementation in Linux. Tushar B. Kute,

Linux Kernel Modules & Device Drivers April 9, 2012

Unix (Linux) Device Drivers

Device Drivers. CS449 Fall 2017

CS 378 (Spring 2003)

Finish up OS topics Group plans

Linux Device Drivers. 3. Char Drivers. 1. Introduction 2. Kernel Modules 3. Char Drivers 4. Advanced Char Drivers 5. Interrupts

Kernel Modules. Kartik Gopalan

Linux Device Driver. Analog/Digital Signal Interfacing

RF-IDs in the Kernel -- Episode III: I want to File Away

Abstraction via the OS. Device Drivers. Software Layers. Device Drivers. Types of Devices. Mechanism vs. Policy. Jonathan Misurda

Software Layers. Device Drivers 4/15/2013. User

ECE 7650 Scalable and Secure Internet Services and Architecture ---- A Systems Perspective. Part I: Operating system overview: Disk and File System

The device driver (DD) implements these user functions, which translate system calls into device-specific operations that act on real hardware

Linux Device Drivers

Introduction Reading Writing scull. Linux Device Drivers - char driver

Linux Loadable Kernel Modules (LKM)

Scrivere device driver su Linux. Better Embedded 2012 Andrea Righi

CIS Operating Systems I/O Systems & Secondary Storage. Professor Qiang Zeng Spring 2018

CIS Operating Systems I/O Systems & Secondary Storage. Professor Qiang Zeng Fall 2017

Storage Systems. NPTEL Course Jan K. Gopinath Indian Institute of Science

CS 423 Operating System Design: Introduction to Linux Kernel Programming (MP1 Q&A)

/dev/hello_world: A Simple Introduction to Device Drivers under Linux

Comp 204: Computer Systems and Their Implementation. Lecture 18: Devices

I/O MANAGEMENT CATEGORIES OF I/O DEVICES 1. Slide 1. Slide 3. Controller: Three classes of devices (by usage):

Designing and developing device drivers. Coding drivers

Loadable Kernel Module

Devices. Today. Comp 104: Operating Systems Concepts. Operating System An Abstract View 05/01/2017. Devices. Devices

FAME Operatinf Systems - Modules

Block Device Driver. Pradipta De

Linux drivers - Exercise

To understand this, let's build a layered model from the bottom up. Layers include: device driver filesystem file

Kthreads, Mutexes, and Debugging. Sarah Diesburg CS 3430 Operating Systems

CSE 333 SECTION 3. POSIX I/O Functions

NPTEL Course Jan K. Gopinath Indian Institute of Science

OS COMPONENTS OVERVIEW OF UNIX FILE I/O. CS124 Operating Systems Fall , Lecture 2

Introduction to Operating Systems. Device Drivers. John Franco. Dept. of Electrical Engineering and Computing Systems University of Cincinnati

I/O Handling. ECE 650 Systems Programming & Engineering Duke University, Spring Based on Operating Systems Concepts, Silberschatz Chapter 13

Linux Device Drivers. 3. Char Drivers cont. 3. Char Drivers. 1. Introduction 2. Kernel Modules 3. Char Drivers 4. Advanced Char Drivers 5.

Rights to copy. Dongkun Shin, SKKU

Operating System Concepts Ch. 11: File System Implementation

Workspace for '5-linux' Page 1 (row 1, column 1)

Operating Systems. V. Input / Output

Table of Contents. Preface... xi

The kernel constitutes the core part of the Linux operating system. Kernel duties:

NPTEL Course Jan K. Gopinath Indian Institute of Science

3 Character Drivers. 3.1 The Design of scullc. Linux Device Drivers in Assembly

CS 453: Operating Systems Programming Project 5 (100 points) Linux Device Driver

CS 471 Operating Systems. Yue Cheng. George Mason University Fall 2017

7.4 Simple example of Linux drivers

STORAGE SYSTEMS. Operating Systems 2015 Spring by Euiseong Seo

Introduction to Device Drivers Part-1

USB. Development of a USB device driver working on Linux and Control Interface. Takeshi Fukutani, Shoji Kodani and Tomokazu Takahashi

CS 0449 Project 4: /dev/rps Due: Friday, December 8, 2017, at 11:59pm

CS 1550 Project 3: File Systems Directories Due: Sunday, July 22, 2012, 11:59pm Completed Due: Sunday, July 29, 2012, 11:59pm

User Space Device Drivers Introduction and Implementation using VGAlib library

[537] I/O Devices/Disks. Tyler Harter

The Journey of an I/O request through the Block Layer

INSTRUMENTATION. using FREE/OPEN CODE

Che-Wei Chang Department of Computer Science and Information Engineering, Chang Gung University

ASE++ : Linux Kernel Programming

What is a Linux Device Driver? Kevin Dankwardt, Ph.D. VP Technology Open Source Careers

Fall 2017 :: CSE 306. File Systems Basics. Nima Honarmand

I/O and Device Drivers

Input/Output Systems

INSTRUMENTATION. using FREE/OPEN CODE

CS330: Operating System and Lab. (Spring 2006) I/O Systems

Character Device Drivers

CPSC 8220 FINAL EXAM, SPRING 2016

Major Device Number specifies the device class, floppy disk, hard disk, terminal (selects device driver)

CS 134. Operating Systems. April 8, 2013 Lecture 20. Input/Output. Instructor: Neil Rhodes. Monday, April 7, 14

Chapter 13: I/O Systems

Linux Kernel Module Programming. Tushar B. Kute,

1 #include <linux/module.h> 2 #include <linux/sched.h> 3 #include <linux/interrupt.h> 4 #include <linux/init.h> 5 #include <linux/kernel.

Module 12: I/O Systems

Design and Implementation of an Asymmetric Multiprocessor Environment Within an SMP System. Roberto Mijat, ARM Santa Clara, October 2, 2007

Storage Systems. NPTEL Course Jan K. Gopinath Indian Institute of Science

I/O. CS 416: Operating Systems Design Department of Computer Science Rutgers University

Block Device Scheduling. Don Porter CSE 506

Block Device Scheduling

Chapter 13: I/O Systems

I/O. Kevin Walsh CS 3410, Spring 2010 Computer Science Cornell University. See: P&H Chapter 6.5-6

Linux Device Driver in Action (LDDiA)

REVISION HISTORY NUMBER DATE DESCRIPTION NAME

CSE 333 SECTION 3. POSIX I/O Functions

Module 12: I/O Systems

Operating Systems 2010/2011

Operating System: Chap13 I/O Systems. National Tsing-Hua University 2016, Fall Semester

Ref: Chap 12. Secondary Storage and I/O Systems. Applied Operating System Concepts 12.1

ECEN 449 Microprocessor System Design. Hardware-Software Communication. Texas A&M University

we are here Page 1 Recall: How do we Hide I/O Latency? I/O & Storage Layers Recall: C Low level I/O

Operating Systems CMPSC 473. Input/Output April 22, Lecture 22 Instructor: Trent Jaeger

CSE 120. Overview. July 27, Day 8 Input/Output. Instructor: Neil Rhodes. Hardware. Hardware. Hardware

Introduction to Linux Device Drivers Recreating Life One Driver At a Time

I/O Systems. Jo, Heeseung

Overview. I/O Devices. Memory Access. Device Controller. Advanced Operating System Project. Device Drivers. M. Muztaba Fuad

Final Step #7. Memory mapping For Sunday 15/05 23h59

I/O Systems. 04/16/2007 CSCI 315 Operating Systems Design 1

CSE380 - Operating Systems. Communicating with Devices

The Active Block I/O Scheduling System (ABISS)

Transcription:

CS5460/6460: Operating Systems Lecture 24: Device drivers Anton Burtsev April, 2014

Device drivers Conceptually Implement interface to hardware Expose some high-level interface to the kernel or applications What this interface should look like? In UNIX everything is a...

Device drivers Conceptually Implement interface to hardware Expose some high-level interface to the kernel or applications What this interface should look like? In UNIX everything is a file

Devices in UNIX In Unix devices expose file-like interface They are files in the file system /dev/sda, /dev/dsp Applications can read and write into them dd if=/dev/sda of=/my-disk-image bs=1m cat thesis.txt > /dev/lp

Classes of devices Character Accessed as a stream of bytes Block Text console, serial ports /dev/console, /dev/tty1 I/O performed in units of blocks Hard disks, CD drives, USB sticks /dev/sda

Classes of devices But what about network devices? Graphic cards? No easy file mapping Although it doesn't mean you can't come up with one if it fits your needs Device as a file paradigm doesn't work Well they expose different interfaces Network cards are accessible through sockets

Detour into hardware

Device drivers and hardware Device driver doesn't strictly need to talk to hardware /dev/random stream of random numbers /dev/mem reads physical memory /dev/null input goes nowhere

Bus subsystem Buses are the mechanism that enable the flow of data across CPU, memory, and devices

Buses PCI (Peripheral Component Interconnect) main system bus on most architectures USB (Universal Serial Bus) external bus, hotplug capability, devices are connected in a tree SCSI (Small Computer System Interface) high-throughput bus used mainly for disks

Interacting with peripherals I/O ports Device is identified by the port number 2^16 ports (64K ports) in, out instructions to read and write data from a port Connect straight to a peripheral

Interacting with peripherals I/O memory mapping Modern CPUs allow mapping port addresses to memory locations Then it's just possible read/write memory GPU devices System buses like PCI

Interacting with peripherals Interrupts CPU provides several interrupt lines One line can be shared across several devices Polling Periodic check of the device state for whether more data is available

Back to the Linux kernel

Linux exports devices as files Lets assume you have a modem attached to the serial port echo "ATZ" > /dev/ttys0 Sends initialization string to the modem To read your hard drive cat /dev/sda

Device files (/dev/xyz)

Major and minor numbers Each device file has two numbers Identify device driver for this device Major number: device driver Minor number: device number wolfgang@meitner> ls -l /dev/sd{a,b} /dev/ttys{0,1} brw-r----- 1 root disk 8, 0 2008-02-21 21:06 /dev/sda brw-r----- 1 root disk 8, 16 2008-02-21 21:06 /dev/sdb crw-rw---- 1 root uucp 4, 64 2007-09-21 21:12 ttys0 crw-rw---- 1 root uucp 4, 65 2007-09-21 21:12 ttys1

/dev Back in the days /dev/ was static Now there are 20K device numbers are allocated Most are not used on your system Today, /dev/ is a temporary file system All device names are generated on the fly By udevd daemon

udevd Udevd listens for hotplug messages from the kernel Creates new device nodes

Implementing device drivers

Kernel modules Linux allows extending itself with kernel modules Most device drivers are implemented as kernel modules Loadable at run-time on demand, when device is detected

Hello world module #include <linux/init.h> #include <linux/module.h> MODULE_LICENSE("Dual BSD/GPL"); static int hello_init(void) { printk(kern_alert "Hello, world\n"); return 0; } static void hello_exit(void) { printk(kern_alert "Goodbye, cruel world\n"); } module_init(hello_init); module_exit(hello_exit);

File operations Remember devices are exported as special files Each device needs to implement a file interface Each inode and file has a pointer to an interface Set of functions which are used for opening, reading, writing, etc. Same with device files Each device file has a pointer to a set of functions

struct file_operations { struct module *owner; File operations loff_t (*llseek) (struct file *, loff_t, int); ssize_t (*read) (struct file *, char *, size_t, loff_t *); ssize_t (*write) (struct file *, const char *, size_t, loff_t *); int (*readdir) (struct file *, void *, filldir_t); unsigned int (*poll) (struct file *, struct poll_table_struct *); int (*ioctl) (struct inode *, struct file *, unsigned, unsigned long); int (*mmap) (struct file *, struct vm_area_struct *); int (*open) (struct inode *, struct file *); int (*flush) (struct file *); int (*release) (struct inode *, struct file *); int (*fsync) (struct file *, struct dentry *, int datasync); int (*fasync) (int, struct file *, int); int (*lock) (struct file *, int, struct file_lock *); ssize_t (*readv) (struct file *, struct iovec *, unsigned, loff_t *); ssize_t (*writev) (struct file *, struct iovec *, unsigned, loff_t *); };

File operations You don't need to implement all file operations Some can remain NULL Kernel will come up with some default behavior static struct file_operations simple_driver_fops = {.owner = THIS_MODULE,.read = device_file_read, };

Register with the kernel Register character device with the kernel static int device_file_major_number = 0; static const char device_name[] = "Simple-driver"; static int register_device(void) { result = register_chrdev( 0, device_name, &simple_driver_fops ); if( result < 0 ) { printk( KERN_WARNING "Simple-driver: can\'t register character device with errorcode = %i", result ); return result; } }; device_file_major_number = result;

Read function ssize_t (*read) (struct file *, char *, size_t, loff_t *); First arg pointer to the file struct Private information for us, e.g. state of this file Second arg buffer in user space to read data into Third arg number of bytes to read Fourth arg position in a file from where to read

static const char hw_string[] = "Hello world from kernel mode!\n\0"; static const ssize_t hw_size = sizeof(hw_string); static ssize_t device_file_read(struct file *file_ptr, char user *user_buffer, size_t count, loff_t *position) { /* If position is behind the end of a file we have nothing to read */ if( *position >= hw_size ) return 0; /* If a user tries to read more than we have, read only as many bytes as we have */ if( *position + count > hw_size ) count = hw_size - *position; if( copy_to_user(user_buffer, hw_string + *position, count)!= 0 ) return -EFAULT; } /* Move reading position */ *position += count; return count;

Build, compile... New device appears in /proc/devices Character devices: 1 mem 4 tty 4 ttys... 250 Simple-driver... Make a device file for our device $> mknod /dev/simple-driver c 250 0 Access device $> cat /dev/simple-driver Hello world from kernel mode!

Block devices

Elevator I/O schedulers Original name is after the way of how elevator moves Up or down, picking up passengers on the way Same with disk Disk arm moves inside or outside Requests are serviced only in the direction of the arm movement until it reaches the edge

Linux elevators Noop First come, first served Deadline Assigns a deadline to each request Tries to reorder requests to minimize seek times for requests before deadline Anticipatory scheduler Tries to anticipate behavior of a process Assumes that reads are not independent, more reads will follow the initial read Delay seeks for some time anticipating reads to a nearby location CFQ (Completely Fair Queuing) Assign each thread a time slice in which it is allowed to submit requests to disk Each thread gets a fair share of I/O throughput

Conclusion

Thank you!