Interrupt handling. Interrupt handling. Deferred work. Interrupt handling. Remove an interrupt handler. 1. Link a struct work to a function
|
|
- Jasper Hampton
- 6 years ago
- Views:
Transcription
1 Interrupt handling Interrupt handling error = request_irq(irq_number, interrupt_service_routine, flags, module_name, (void*)dataptr); error: == 0 OK!= 0 FAILED interrupt_service_routine: irqreturn_t interrupt_service_routine(int irq_number, void *dataptr); flags one or more: IRQF_SHARED IRQF_TRIGGER_RISING IRQF_TRIGGER_FALLING interrupt_service_routine: irqreturn_t interrupt_service_routine(int irq_number, void *dataptr); No process context No current No copy_from_user or copy_to_user No sleeping No semaphores or mutexes No kmalloc(, GFP_KERNEL) No msleep or ssleep Shared interrupt: check if it is your interrupt (use dataptr) Be fast (defer work if needed) Return IRQ_NONE or IRQ_HANDLED Interrupt handling Deferred work Remove an interrupt handler free_irq(irq_number, dataptr); 1. Link a struct work to a function INIT_WORK(&userdata->work, workfunction); 2a. Create a queue of works (struct workqueue_struct) qptr = create_workqueue("workqueue name"); qptr = create_singlethread_workqueue("workqueue name"); 3a. Add the work to the queue queue_work(qptr, &userdata->work); queue_delayed_work(qptr, &userdata->work, delay); 2b. Add the work to a shared queue schedule_work(&userdata->work);
2 Deferred work Deferred work Safely remove a private workqueue destroy_workqueue(device.wq); Safely remove a work from shared queue cancel_work_sync(&device.work); #include <linux/workqueue.h> /* struct to keep user data and work info */ struct mystruct struct work_struct work; userdata; void workfunction(struct work_struct *work) /* deferred work function */ INIT_WORK(&userdata->work, workfunction); wq = create_singlethread_workqueue("workqueue_name");. queue_work(wq, &userdata.work); /* use a private workqueue */ Deferred work Delay (long) #include <linux/workqueue.h> /* struct to keep user data and work info */ struct mystruct struct work_struct work; userdata; delay = delay_seconds*hz; wait_queue_head_t waitq; init_waitqueue_head(&waitq); wait_event_interruptible_timeout(waitq, 0, delay); /* wait until timeout or somebody calls wake_up on waitq return value: 0 => timeout expired > 0 => remaining delay */ void workfunction(struct work_struct *work) /* deferred work function */ INIT_WORK(&userdata->work, workfunction); schedule_work(&userdata->work); /* use a default (shared) workqueue */ delay = delay_seconds*hz; set_current_state(task_interruptible); schedule_timeout(delay); /* return value: 0 => timeout expired > 0 => remaining delay */
3 Delay (short) Timers /* scheduled wait */ msleep(delay_in_ms); msleep_interruptible(delay_in_ms); ssleep(delay_in_s); /* busy wait */ ndelay(delay_in_ns); udelay(delay_in_us); mdelay(delay_in_ms); void timer_function(unsigned long timerdata) /* will run at interrupt time (on the same CPU which registered it) no access at user space current is meaningless no sleeping no kmalloc(, GFP_KERNEL) no semaphores no schedule() no wait_event */ add_timer(); // if needed struct timer_list T = TIMER_INITIALIZER(timer_function, jiffies+delay, timerdata); add_timer(&t); /* others; int timer_pending(const struct timer_list * timer); int mod_timer(struct timer_list *timer, unsigned long new_expires); int del_timer(struct timer_list * timer); int del_timer_sync(struct timer_list * timer); (may sleep) */ GPIO functions int gpio_is_valid(int pin_idx);!= 0 : pin is valid == 0 : pin is not valid int gpio_request(int pin_idx, char *pin_label /* optional */); < 0 : error void gpio_free(int pin_idx); int gpio_cansleep(int pin_idx);!= 0 : access to pin can sleep int gpio_direction_input(int pin_idx); < 0 : error Use a pushbutton to pulse a led (if not already pulsing) Button press irq deferred scheduling of a pulsing function Write: change the number of pulses and activate pulsing (if not already active) Read: get the number of pulses (default or last written) int gpio_direction_output(int pin_idx, int pin_value); < 0 : error void gpio_set_value(int pin_idx, int pin_value); int gpio_get_value(int pin_idx); int gpio_to_irq(int pin_idx); < 0 : error >= 0 irq related to pin Keep track of: Total number of pulses performed Total number of IRQs received Total number of IRQs actually handled
4 Module initialization Register a major number Reserve needed GPIOs Request an IRQ Connect to interrupt service routine Prepare deferred work Create an entry in /proc/driver Module cleanup Free the /proc/driver entry Free the IRQ Free GPIOs Remove deferred work #ifndef _IRQCE2_H_INCLUDED #define _IRQCE2_H_INCLUDED #define LINE_IN 7 #define LINE_OUT 139 #ifdef CONFIG_MACH_OMAP3_BEAGLE #define LED_OUT 149 #else #define LED_OUT 0 #endif #define PULSE_DELAY_MS 300 #define DEFAULT_NPULSES 3 #define MAX_NPULSES 10 #define MODNAME "irqce2" On beagleboard: 7: GPIO connected to a pushbutton 139: GPIO connected to expansion header 149: GPIO connected to a board led We pulse on line_out and on led_out There is no warranty we are really writing on a led. To be safe: - use a fixed value for LED_OUT (no module parameter); - ensure we are running on a beagleboard by checking the macro CONFIG_MACH_OMAP3_BEAGLE) irq_ce2.h typedef struct struct cdev cdev; /* char device structure */ struct semaphore sem; /* synchronization */ unsigned npulses; /* pulses to do each time */ unsigned long pulses_done; /* overall pulses performed */ int irq; /* irq reserved for device */ unsigned long irq_received; unsigned long irq_handled; int pulsing; /* currently pulsing */ spinlock_t pulsing_lock; /* setting pulsing must be atomic */ int last_input; /* last value read on input pin */ int last_output; /* last value written on input pin */ int can_read; /* only one read */ int can_write; /* only one write */ extern struct file_operations irqce2_funcs; int irqce2_init_module(void); void irqce2_cleanup_module(void); irqreturn_t irqce2_isr(int irq, void *dev_id); void pulsefunction(struct work_struct *work); int read_procmem(char *buf, char **start, off_t offset, int count, int *eof, void *data); #endif /* _IRQCE2_H_INCLUDED */ struct work_struct work; /* for deferred work */ struct workqueue_struct *wq; irqce2_device_descr; irq_ce2.h irq_ce2.h
5 #include <linux/module.h> #include <linux/moduleparam.h> #include <linux/init.h> #include <linux/kernel.h> #include <linux/fs.h> #include <linux/errno.h> #include <linux/slab.h> #include <linux/types.h> #include <asm/system.h> #include <asm/uaccess.h> #include <linux/fcntl.h> #include <linux/proc_fs.h> #include <linux/seq_file.h> #include <linux/cdev.h> #include <linux/interrupt.h> #include <linux/sched.h> #include <linux/delay.h> #include <linux/gpio.h> #include "irq_ce2.h" MODULE_AUTHOR("Calcolatori Elettronici 2 (uniud)"); MODULE_DESCRIPTION("Example for irq and deferred work"); MODULE_VERSION("0:1.0"); MODULE_LICENSE("Dual BSD/GPL"); /* parameters */ int line_in = LINE_IN; int line_out = LINE_OUT; Default values int pulsems = PULSE_DELAY_MS; /* permission flag: S_IRUSR / S_IWUSR / S_IXUSR : read / write / exec for user (owner) S_IRWXU: read-write-exec for user S_IRGRP, S_IWGRP, S_IXGRP, S_IRWXG: permissions for group S_IROTH, S_IWOTH, S_IXOTH, S_IRWXO: permissions for others S_IRUGO / S_IWUGO / S_IXUGO: read / write / exec for all S_IRWXUGO: read-write-exec for all */ module_param(line_in, int, S_IRUGO); module_param(line_out, int, S_IRUGO); Default values can be overridden at load time module_param(pulsems, int, S_IRUGO); (we use 0 for line_in or line_out to not use such pins) /* globals */ irqce2_device_descr device; int major = 0; int minor = 0; /* allocate gpio pins line_in and line_out */ int allocate_pins(void) int ret; if ( (line_in &&!gpio_is_valid(line_in)) (line_out &&!gpio_is_valid(line_out)) ) if (line_in) ret = gpio_request(line_in, "v"); if (ret < 0) ret = gpio_direction_input(line_in); if (ret < 0) goto fail1; Ensure we are using valid GPIOs Require the input pin if (line_out) ret = gpio_request(line_out, "^"); if (ret < 0) goto fail1; ret = gpio_direction_output(line_out, 0); if (ret < 0) goto fail2; if ( (line_in && gpio_cansleep(line_in)) (line_out && gpio_cansleep(line_out)) ) goto fail2; if ( LED_OUT && gpio_cansleep(led_out) ) goto fail2; return 1; /* OK */ Require the output pin (led is already allocated) We need non-sleeping GPIOs
6 fail2: if (line_out) gpio_free(line_out); fail1: if (line_in) gpio_free(line_in); /* FAIL */ /* release gpio pins line_in and line_out */ void free_pins(void) if (line_out) gpio_free(line_out); if (line_in) gpio_free(line_in); /* allocate irq for line_in */ int allocate_irq(void) int irq; int error; if (!line_in) return 1; irq = gpio_to_irq(line_in); if (irq < 0) error = irq; printk(kern_info MODNAME ": Unable to get irq: error %d\n", error); error = request_irq(irq, irqce2_isr, IRQF_SHARED IRQF_TRIGGER_RISING IRQF_TRIGGER_FALLING, MODNAME, (void*)&device); Shared IRQ, triggered by both rising and falling signal edge (actually falling edge is not used in isr) if (error) printk(kern_info MODNAME ": Unable to claim irq %d; error %d\n", irq, error); device.irq = irq; return 1;
7 /* release irq for line_in */ void release_irq(void) if (!line_in) return; free_irq(device.irq, &device); or: free_irq(gpio_to_irq(line_in), &device); /* write on pin line_out and on led LED_OUT */ void writeoutpin(int v) if (line_out) gpio_set_value(line_out, v); if (LED_OUT) gpio_set_value(led_out, v); device.last_output = v; /* read from pin line_in */ int readinpin(void) if (line_in) return gpio_get_value(line_in); else /* driver interrupt handler */ irqreturn_t irqce2_isr(int irq, void *dev_id) irqce2_device_descr *d = dev_id; int lineval; unsigned long irqflags; d->irq_received++; lineval = readinpin(); if ( lineval == d->last_input ) return IRQ_NONE; /* not on my line */ else d->last_input = lineval; d->irq_handled++; Shared IRQ: test if this is for me if ( d->last_input == 1 ) /* critical section: Rising edge: button is pressed 1. no semaphores in interrupt handlers 2. for lock used within interrupt handlers the safe version (spin_lock_irqsave and spin_unlock_irqrestore) must be used */ spin_lock_irqsave(&device.pulsing_lock, irqflags); if (! d->pulsing ) /* activate pulses on output */ d->pulsing = 1; #ifdef USE_SHARED_QUEUE schedule_work(&device.work); #else queue_work(device.wq, &device.work); #endif spin_unlock_irqrestore(&device.pulsing_lock, irqflags); Access to pulsing and deferred work scheduling must be exclusive return IRQ_HANDLED;
8 /* driver interface functions */ /* Module init */ int init irqce2_init_module(void) dev_t dev = 0; int err, devno; err = alloc_chrdev_region(&dev, minor, 1, MODNAME); major = MAJOR(dev); if (err < 0) printk(kern_warning MODNAME ": can't get major %d\n", major); return err; devno = MKDEV(major, 0); memset(&device, 0, sizeof(irqce2_device_descr)); if (!allocate_pins() ) printk(kern_info MODNAME ": Failed to allocate pins\n"); err = -ENOSR; goto fail1; if ( line_in &&!allocate_irq() ) printk(kern_info MODNAME ": Failed to allocate irq\n"); err = -ENOSR; goto fail2; sema_init(&device.sem, 1); cdev_init(&device.cdev, &irqce2_funcs); device.cdev.owner = THIS_MODULE; device.cdev.ops = &irqce2_funcs; device.npulses = DEFAULT_NPULSES; device.can_read = 1; device.can_write = 1; device.pulsing_lock = SPIN_LOCK_UNLOCKED; INIT_WORK(&device.work, pulsefunction); #ifndef USE_SHARED_QUEUE /* pulsefunction will sleep hence use a private workqueue */ device.wq = create_singlethread_workqueue(modname "WQ"); #endif err = cdev_add (&device.cdev, devno, 1); /* device is live now */ if (err) /* registration failed */ printk(kern_notice MODNAME ": Error %d adding device\n", err); goto fail3; create_proc_read_entry("driver/" MODNAME, /* name */ 0, /* mode (0:default) */ NULL, /* parent dir */ read_procmem, NULL /* client data */); /* OK */ fail3: if (line_in) release_irq(); fail2: free_pins(); fail1: unregister_chrdev_region(devno, 1); return err; /* FAIL */ /* Module cleanup */ void exit irqce2_cleanup_module(void) int devno; remove_proc_entry("driver/" MODNAME, NULL); if (line_in) release_irq(); free_pins(); cdev_del(&device.cdev); devno = MKDEV(major, minor); unregister_chrdev_region(devno, 1); #ifdef USE_SHARED_QUEUE cancel_work_sync(&device.work); #else destroy_workqueue(device.wq); #endif
9 /* Device open */ int irqce2_open(struct inode *inode, struct file *file) irqce2_device_descr *dev; dev = container_of(inode->i_cdev, irqce2_device_descr, cdev); file->private_data = dev; dev->can_read = 1; dev->can_write = 1; /* Device close */ int irqce2_release(struct inode *inode, struct file *file) /* Read */ ssize_t irqce2_read(struct file *file, char *buffer, size_t count, loff_t *offset) irqce2_device_descr *d = file->private_data; char buff[80]; ssize_t ret = 0; int datalen; if (down_interruptible(&d->sem)) return -ERESTARTSYS; if ( d->can_read ) sprintf(buff, "npulses: %d\n", d->npulses); datalen = strlen(buff); if ( copy_to_user(buffer, buff, datalen) ) ret = -EFAULT; else *offset += datalen; ret = datalen; d->can_read = 0; else ret = 0; up(&d->sem); return ret; /* Write */ ssize_t irqce2_write(struct file *file, const char *buffer, size_t count, loff_t *offset) irqce2_device_descr *d = file->private_data; unsigned long irqflags; char buff[80]; ssize_t ret = 0; int npulses; if (down_interruptible(&d->sem)) return -ERESTARTSYS; if ( d->can_write &! d->pulsing ) if (count >= sizeof(buff)) count = sizeof(buff)-1; if (copy_from_user(buff, buffer, count)) ret = -EFAULT; else buff[sizeof(buff)-1] = 0; if (! sscanf(buff, "%d", &npulses) ) /* invalid input */ ret = 0; else if (npulses > MAX_NPULSES) npulses = MAX_NPULSES; ret = count;
10 spin_lock_irqsave(&device.pulsing_lock, irqflags); if (! d->pulsing ) d->npulses = npulses; *offset += count; ret = count; d->can_write = 0; d->pulsing = 1; #ifdef USE_SHARED_QUEUE schedule_work(&d->work); #else queue_work(d->wq, &d->work); #endif else ret = 0; spin_unlock_irqrestore(&device.pulsing_lock, irqflags); else ret = 0; up(&d->sem); return count; Access to pulsing and deferred work scheduling must be exclusive /* Deferred work */ void pulsefunction(struct work_struct *work) irqce2_device_descr *d = container_of(work, irqce2_device_descr, work); unsigned long irqflags; int i; for (i=0 ; i<d->npulses ; i++) writeoutpin(1); msleep(pulsems); writeoutpin(0); d->pulses_done++; if (i<d->npulses) msleep(pulsems); spin_lock_irqsave(&device.pulsing_lock, irqflags); d->pulsing = 0; spin_unlock_irqrestore(&device.pulsing_lock, irqflags); /* Proc file function */ int read_procmem(char *buf, char **start, off_t offset, int count, int *eof, void *data) const char formatstr[] = "IRQ is %d, npulses is %d\n" "Received %ld irqs, %ld handled\n" "Generated %ld pulses\n"; char str[sizeof(formatstr)+5*9*2]; struct file_operations irqce2_funcs = owner: THIS_MODULE, open: irqce2_open, release: irqce2_release, read: irqce2_read, write: irqce2_write, ; sprintf(str, formatstr, device.irq, device.npulses, device.irq_received, device.irq_handled, device.pulses_done); strncpy(buf, str, count-1); buf[count-1] = 0; *eof = 1; return strlen(buf); module_init(irqce2_init_module); module_exit(irqce2_cleanup_module);
11 # If KERNELRELEASE is defined, we've been invoked from the # kernel build system and can use its language. ifneq ($(KERNELRELEASE),) obj-m := irq_ce2.o # Otherwise we were called directly from the command # line; invoke the kernel build system. else KERNELDIR?= /lib/modules/$(shell uname -r)/build PWD := $(shell pwd) default: $(MAKE) -C $(KERNELDIR) M=$(PWD) modules endif $ insmod./irq_ce2.ko $ lsmod $ ls /sys/module/irq_ce2/parameters/ $ cat /sys/module/irq_ce2/parameters/pulsems $ cat /proc/kallsyms grep irqce2 $ cat /proc/interrupts $ cat /proc/devices grep irqce2 $ mknod e c press the pushbutton (and see the led pulsing) $ echo 5 > e Test 1 (shared workqueue) Build with: make \ KERNELDIR=<binary_kernel_dir> \ ARCH=arm \ CROSS_COMPILE=arm-none-linux-gnueabi- \ EXTRA_CFLAGS=-DUSE_SHARED_QUEUE $ echo 5 > e ; while true ; do echo -n "a " ; sleep 1 ; done $ cat /proc/driver/irqce2 Makefile $ cat e $ rmmod irq_ce2 Test 2 (private workqueue) Build with: make \ KERNELDIR=<binary_kernel_dir> \ ARCH=arm \ CROSS_COMPILE=arm-none-linux-gnueabi- After module rebuilding, perform previous test again
Simple char driver. for Linux. my_first.c: headers. my_first.c: file structure. Calcolatori Elettronici e Sistemi Operativi.
Calcolatori Elettronici e Sistemi Operativi Simple char driver Simple char driver for Linux Code organization my_first.c driver code: Headers Macro definitions Device structure definition Globals and module
More informationREVISION HISTORY NUMBER DATE DESCRIPTION NAME
i ii REVISION HISTORY NUMBER DATE DESCRIPTION NAME iii Contents 1 The structure of a Linux kernel module 1 1.1 Install XV6...................................................... 1 1.2 Compile and load a
More informationCharacter Device Drivers One Module - Multiple Devices
Review from previous classes Three Types: Block, Character, and Network Interface Device Drivers MAJOR & MINOR numbers assigned register_chrdev_region(), alloc_chrdev_region(), unregister_chrdev_region()
More informationLinux Device Drivers
Linux Device Drivers Modules A piece of code that can be added to the kernel at runtime is called a module A device driver is one kind of module Each module is made up of object code that can be dynamically
More information7.4 Simple example of Linux drivers
407 7.4 Simple example of Linux drivers In the previous section, we introduce a simple Hello module driver, it is just some information from the serial port output, the board did not correspond to the
More informationIntroduction Reading Writing scull. Linux Device Drivers - char driver
Overview 1 2 3 4 Major, minor File Operations The file Structure The inode structure Registraction simplest driver, suitable for most simple devices, follow the book. Jernej Figure: Vičič. (Simple Character
More information1 #include <linux/module.h> 2 #include <linux/sched.h> 3 #include <linux/interrupt.h> 4 #include <linux/init.h> 5 #include <linux/kernel.
1 #include 2 #include 3 #include 4 #include 5 #include 6 #include 7 #include 8 #include
More informationCS 423 Operating System Design: Introduction to Linux Kernel Programming (MP1 Q&A)
CS 423 Operating System Design: Introduction to Linux Kernel Programming (MP1 Q&A) Professor Adam Bates Fall 2018 Learning Objectives: Talk about the relevant skills required in MP1 Announcements: MP1
More informationLinux Device Drivers Interrupt Requests
Overview 1 2 3 Installation of an interrupt handler Interface /proc 4 5 6 7 primitive devices can be managed only with I/O regions, most devices require a more complicated approach, devices cooperate with
More informationLoadable Kernel Module
Instituto Superior de Engenharia do Porto Mestrado em Engenharia Eletrotécnica e de Computadores Arquitetura de Computadores Loadable Kernel Module The objective of this lesson is to analyze, compile and
More informationLinux Kernel Modules & Device Drivers April 9, 2012
Linux Kernel Modules & Device Drivers April 9, 2012 Pacific University 1 Resources Linux Device Drivers,3rd Edition, Corbet, Rubini, Kroah- Hartman; O'Reilly kernel 2.6.10 we will use 3.1.9 The current
More informationKernel Modules. Kartik Gopalan
Kernel Modules Kartik Gopalan Kernel Modules Allow code to be added to the kernel, dynamically Only those modules that are needed are loaded. Unload when no longer required - frees up memory and other
More informationFinish up OS topics Group plans
Finish up OS topics Group plans Today Finish up and review Linux device driver stuff Walk example again See how it all goes together Discuss talking to MMIO RTOS (on board) Deferred interrupts Discussion
More informationREVISION HISTORY NUMBER DATE DESCRIPTION NAME
i ii REVISION HISTORY NUMBER DATE DESCRIPTION NAME iii Contents 1 Walking through the Assignment 2 1 1.1 Preparing the base code from Assignment 1..................................... 1 1.2 Dummy port
More informationLinux Device Driver in Action (LDDiA)
Linux Device Driver in Action (LDDiA) Duy-Ky Nguyen 2015-04-30 1. On Memory Any unit under user control must have a controller board (CB) with a controller unit (CU) and several devices (Dev.x) doing what
More informationCharacter Device Drivers
Character Device Drivers 張大緯 CSIE, NCKU The information on the slides are from Linux Device Drivers, Third Edition, by Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman. Copyright 2005 O Reilly
More informationVirtual File System (VFS) Implementation in Linux. Tushar B. Kute,
Virtual File System (VFS) Implementation in Linux Tushar B. Kute, http://tusharkute.com Virtual File System The Linux kernel implements the concept of Virtual File System (VFS, originally Virtual Filesystem
More informationStep Motor. Step Motor Device Driver. Step Motor. Step Motor (2) Step Motor. Step Motor. source. open loop,
Step Motor Device Driver Step Motor Step Motor Step Motor source Embedded System Lab. II Embedded System Lab. II 2 Step Motor (2) open loop, : : Pulse, Pulse,, -, +5%, step,, Step Motor Step Motor ( ),
More informationMP3: VIRTUAL MEMORY PAGE FAULT MEASUREMENT
MP3: VIRTUAL MEMORY PAGE FAULT MEASUREMENT University of Illinois at Urbana-Champaign Department of Computer Science CS423 Fall 2011 Keun Soo Yim GOAL A Linux kernel module to profile VM system events
More informationCS 378 (Spring 2003)
Department of Computer Sciences THE UNIVERSITY OF TEXAS AT AUSTIN CS 378 (Spring 2003) Linux Kernel Programming Yongguang Zhang (ygz@cs.utexas.edu) Copyright 2003, Yongguang Zhang This Lecture Device Driver
More informationNPTEL Course Jan K. Gopinath Indian Institute of Science
Storage Systems NPTEL Course Jan 2012 (Lecture 18) K. Gopinath Indian Institute of Science Spinlocks & Semaphores Shared data betw different parts of code in kernel most common: access to data structures
More informationLinux drivers - Exercise
Embedded Realtime Software Linux drivers - Exercise Scope Keywords Prerequisites Contact Learn how to implement a device driver for the Linux OS. Linux, driver Linux basic knowledges Roberto Bucher, roberto.bucher@supsi.ch
More informationThe device driver (DD) implements these user functions, which translate system calls into device-specific operations that act on real hardware
Introduction (Linux Device Drivers, 3rd Edition (www.makelinux.net/ldd3)) Device Drivers -> DD They are a well defined programming interface between the applications and the actual hardware They hide completely
More informationNPTEL Course Jan K. Gopinath Indian Institute of Science
Storage Systems NPTEL Course Jan 2012 (Lecture 17) K. Gopinath Indian Institute of Science Accessing Devices/Device Driver Many ways to access devices under linux Non-block based devices ( char ) - stream
More informationAdvanced Operating Systems #13
http://www.pf.is.s.u-tokyo.ac.jp/class.html Advanced Operating Systems #13 Shinpei Kato Associate Professor Department of Computer Science Graduate School of Information Science and Technology
More informationUSB. Development of a USB device driver working on Linux and Control Interface. Takeshi Fukutani, Shoji Kodani and Tomokazu Takahashi
Linux USB Development of a USB device driver working on Linux and Control Interface Takeshi Fukutani, Shoji Kodani and Tomokazu Takahashi Recently, it s becoming more popular to utilize Linux for controlling
More informationEmbedded Systems Programming
Embedded Systems Programming Work Queue and Input Processing in Linux (Module 16) Yann-Hang Lee Arizona State University yhlee@asu.edu (480) 727-7507 Summer 2014 Example of Work Structure and Handler #include
More informationDesigning and developing device drivers. Coding drivers
Designing and developing device drivers Coding drivers Registering a driver 2 calls to register a driver defined in int register_chrdev_region(dev_t first, unsigned int count, char *name);
More informationOperating systems for embedded systems
Operating systems for embedded systems Embedded operating systems How do they differ from desktop operating systems? Programming model Process-based Event-based How is concurrency handled? How are resource
More informationOperating systems for embedded systems. Embedded Operating Systems
Operating systems for embedded systems Embedded operating systems How do they differ from desktop operating systems? Programming model Process-based Event-based How is concurrency handled? How are resource
More information/dev/hello_world: A Simple Introduction to Device Drivers under Linux
Published on Linux DevCenter (http://www.linuxdevcenter.com/) See this if you're having trouble printing code examples /dev/hello_world: A Simple Introduction to Device Drivers under Linux by Valerie Henson
More informationCPSC 8220 FINAL EXAM, SPRING 2016
CPSC 8220 FINAL EXAM, SPRING 2016 NAME: Questions are short answer and multiple choice. For each of the multiple choice questions, put a CIRCLE around the letter of the ONE correct answer. Make sure that
More informationFAME Operatinf Systems - Modules
FAME Operatinf Systems - Modules 2012 David Picard Contributions: Arnaud Revel, Mickaël Maillard picard@ensea.fr Introduction Linux is not a monolithic pile of code anymore Possibility to add/remove functionalities
More informationRicardo Rocha. Department of Computer Science Faculty of Sciences University of Porto
Ricardo Rocha Department of Computer Science Faculty of Sciences University of Porto For more information please consult Advanced Programming in the UNIX Environment, 3rd Edition, W. Richard Stevens and
More informationDevice Drivers Demystified ESC 117. Doug Abbott, Principal Consultant Intellimetrix. Why device drivers? What s a device driver?
ESC 117, Principal Consultant Intellimetrix Outline Introduction Why device drivers? What s a device driver? Abstract model of device driver OS agnostic What makes drivers seem complicated? Independently
More informationLinux Kernel Development (LKD)
Linux Kernel Development (LKD) Session 2 CISTER Framework: Laboratory 2 Paulo Baltarejo Sousa pbs@isep.ipp.pt 2017 1 Introduction The goal of the CISTER framework is to create a set of tools that help
More informationASE++ : Linux Kernel Programming
ASE++ : Linux Kernel Programming Giuseppe Lipari (giuseppe.lipari@univ-lille.fr) April 8, 2018 Contents 1 Introduction 1 2 Setting up the environment 2 3 Writing a kernel module 5 4 Other useful information
More informationAbstraction via the OS. Device Drivers. Software Layers. Device Drivers. Types of Devices. Mechanism vs. Policy. Jonathan Misurda
Abstraction via the OS Device Drivers Jonathan Misurda jmisurda@cs.pitt.edu Software Layers level I/O software & libraries Device independent OS software Device drivers Interrupt handlers Hardware Operating
More informationLinux Device Drivers. 3. Char Drivers cont. 3. Char Drivers. 1. Introduction 2. Kernel Modules 3. Char Drivers 4. Advanced Char Drivers 5.
Linux Device Drivers Dr. Wolfgang Koch Friedrich Schiller University Jena Department of Mathematics and Computer Science Jena, Germany wolfgang.koch@uni-jena.de Linux Device Drivers 1. Introduction 2.
More informationSoftware Layers. Device Drivers 4/15/2013. User
Software Layers Device Drivers User-level I/O software & libraries Device-independent OS software Device drivers Interrupt handlers Hardware User Operating system (kernel) Abstraction via the OS Device
More informationLinux Kernel Module Programming. Tushar B. Kute,
Linux Kernel Module Programming Tushar B. Kute, http://tusharkute.com Kernel Modules Kernel modules are piece of code, that can be loaded and unloaded from kernel on demand. Kernel modules offers an easy
More informationHyo-bong Son Computer Systems Laboratory Sungkyunkwan University
File I/O Hyo-bong Son (proshb@csl.skku.edu) Computer Systems Laboratory Sungkyunkwan University http://csl.skku.edu Unix Files A Unix file is a sequence of m bytes: B 0, B 1,..., B k,..., B m-1 All I/O
More informationPreview. System Call. System Call. System Call. System Call. Library Functions 9/20/2018. System Call
Preview File Descriptors for a Process for Managing Files write read open close lseek A system call is a request for the operating system to do something on behalf of the user's program. The system calls
More informationCS5460/6460: Operating Systems. Lecture 24: Device drivers. Anton Burtsev April, 2014
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
More informationLinux Device Drivers. 3. Char Drivers. 1. Introduction 2. Kernel Modules 3. Char Drivers 4. Advanced Char Drivers 5. Interrupts
Linux Device Drivers Dr. Wolfgang Koch Friedrich Schiller University Jena Department of Mathematics and Computer Science Jena, Germany wolfgang.koch@uni-jena.de Linux Device Drivers 1. Introduction 2.
More informationDevice Drivers. CS449 Fall 2017
Device Drivers CS449 Fall 2017 Software Layers User-level I/O so7ware & libraries Device-independent OS so7ware Device drivers Interrupt handlers User OperaEng system (kernel) Hardware Device Drivers User
More informationConcurrency Aspects of Project 2
Locking Concurrency Aspects of Project 2 Multiple producers, one consumer Multiple users can issue system calls at the same time Need to protect all shared data Examples Passengers may appear on a floor
More informationInterrupt Handler: Bottom Half. Changwoo Min
1 Interrupt Handler: Bottom Half Changwoo Min 2 Project 3 TA Jinwoo Yom (jinwoo@vt.edu) 3 Hands-on day and office hours Hands-on day (10/09, Tue) In-class design discussion Led by the Project TA, Jinwoo
More informationDevice Drivers. Device Driver. Device Driver. Driver request. Calcolatori Elettronici e Sistemi Operativi. Receive requests. Interact with device(s)
Calcolatori Elettronici e Sistemi Operativi Device Driver Device Drivers Receive requests From user-level code (through syscalls) From kernel-level code Interact with device(s) Send commands Read responses
More informationThe Note/1 Driver Design
Nathan Lay Kelly Hirai 6/14/06 Device Drivers The Note/1 Driver Design Introduction The Music Quest Note/1 midi engine is a small midi controller that communicates over the parallel port. It features two
More informationSuSE Labs / Novell.
Write a real Linux driver Greg Kroah-Hartman SuSE Labs / Novell http://www.kroah.com/usb.tar.gz gregkh@suse.de greg@kroah.com Agenda Intro to kernel modules sysfs basics USB basics Driver to device binding
More informationIntroduction to Linux Device Drivers Recreating Life One Driver At a Time
Introduction to Linux Device Drivers Recreating Life One Driver At a Time Muli Ben-Yehuda mulix@mulix.org IBM Haifa Research Labs, Haifa Linux Club Linux Device Drivers, Technion, Jan 2004 p.1/42 why write
More informationSystem Calls. Library Functions Vs. System Calls. Library Functions Vs. System Calls
System Calls Library Functions Vs. System Calls A library function: Ordinary function that resides in a library external to the calling program. A call to a library function is just like any other function
More informationIntroduction to Operating Systems. Device Drivers. John Franco. Dept. of Electrical Engineering and Computing Systems University of Cincinnati
Introduction to Operating Systems Device Drivers John Franco Dept. of Electrical Engineering and Computing Systems University of Cincinnati Basic Computer Architecture CPU Main Memory System Bus Channel
More informationConcurrency and Race Conditions (Linux Device Drivers, 3rd Edition (www.makelinux.net/ldd3))
(Linux Device Drivers, 3rd Edition (www.makelinux.net/ldd3)) Concurrency refers to the situation when the system tries to do more than one thing at once Concurrency-related bugs are some of the easiest
More informationTCSS 422: OPERATING SYSTEMS
TCSS 422: OPERATING SYSTEMS fork() Process API, Limited Direct Execution Wes J. Lloyd Institute of Technology University of Washington - Tacoma Creates a new process - think of a fork in the road Parent
More informationCSI 402 Lecture 11 (Unix Discussion on Files continued) 11 1 / 19
CSI 402 Lecture 11 (Unix Discussion on Files continued) 11 1 / 19 User and Group IDs Ref: Chapter 3 of [HGS]. Each user is given an ID (integer) called uid. (Most system programs use uid instead of the
More informationWhat is a Linux Device Driver? Kevin Dankwardt, Ph.D. VP Technology Open Source Careers
What is a Linux Device Driver? Kevin Dankwardt, Ph.D. VP Technology Open Source Careers kdankwardt@oscareers.com What does a driver do? Provides a more convenient interface to user-space for the hardware.
More informationCMPSC 311- Introduction to Systems Programming Module: Input/Output
CMPSC 311- Introduction to Systems Programming Module: Input/Output Professor Patrick McDaniel Fall 2014 Input/Out Input/output is the process of moving bytes into and out of the process space. terminal/keyboard
More informationScrivere device driver su Linux. Better Embedded 2012 Andrea Righi
Scrivere device driver su Linux Agenda Overview Kernel-space vs user-space programming Hello, world! kernel module Writing a character device driver Example(s) Q/A Overview What's a kernel? The kernel
More information- Knowledge of basic computer architecture and organization, ECE 445
ECE 446: Device Driver Development Fall 2014 Wednesdays 7:20-10 PM Office hours: Wednesdays 6:15-7:15 PM or by appointment, Adjunct office Engineering Building room 3707/3708 Last updated: 8/24/14 Instructor:
More informationUnix (Linux) Device Drivers
Unix (Linux) Device Drivers Kernel module that handles the interaction with an specific hardware device, hiding its operational details behind a common interface Three basic categories Character Block
More informationReal Time and Embedded Systems. by Dr. Lesley Shannon Course Website:
Real Time and Embedded Systems by Dr. Lesley Shannon Email: lshannon@ensc.sfu.ca Course Website: http://www.ensc.sfu.ca/~lshannon/courses/ensc351 Simon Fraser University Slide Set: 8 Date: November 15,
More informationPMON Module An Example of Writing Kernel Module Code for Debian 2.6 on Genesi Pegasos II
Freescale Semiconductor Application Note AN2744 Rev. 1, 12/2004 PMON Module An Example of Writing Kernel Module Code for Debian 2.6 on Genesi Pegasos II by Maurie Ommerman CPD Applications Freescale Semiconductor,
More informationLecture 3. Introduction to Unix Systems Programming: Unix File I/O System Calls
Lecture 3 Introduction to Unix Systems Programming: Unix File I/O System Calls 1 Unix File I/O 2 Unix System Calls System calls are low level functions the operating system makes available to applications
More informationLoadable Kernel Modules
Loadable Kernel Modules Kevin Dankwardt, Ph.D. kevin.dankwardt@gmail.com Topics 1. Why loadable kernel modules? 2. Using Modules 3. Writing modules 4. Compiling & Installing Modules 5. Example : Simple
More informationHow do we define pointers? Memory allocation. Syntax. Notes. Pointers to variables. Pointers to structures. Pointers to functions. Notes.
, 1 / 33, Summer 2010 Department of Computer Science and Engineering York University Toronto June 15, 2010 Table of contents, 2 / 33 1 2 3 Exam, 4 / 33 You did well Standard input processing Testing Debugging
More informationShared Memory Memory mapped files
Shared Memory Memory mapped files 1 Shared Memory Introduction Creating a Shared Memory Segment Shared Memory Control Shared Memory Operations Using a File as Shared Memory 2 Introduction Shared memory
More informationKernel. Kernel = computer program that connects the user applications to the system hardware Handles:
Kernel programming Kernel Kernel = computer program that connects the user applications to the system hardware Handles: Memory management CPU scheduling (Process and task management) Disk management User
More informationSummer June 15, 2010
Summer 2010 Department of omputer Science and Engineering York University Toronto June 15, 2010 1 / 33 Table of contents 1 2 3 2 / 33 Plan 1 2 3 3 / 33 Exam summary You did well Standard input processing
More informationDesign and Implementation of an Asymmetric Multiprocessor Environment Within an SMP System. Roberto Mijat, ARM Santa Clara, October 2, 2007
Design and Implementation of an Asymmetric Multiprocessor Environment Within an SMP System Roberto Mijat, ARM Santa Clara, October 2, 2007 1 Agenda Design Principle ARM11 MPCore TM overview System s considerations
More informationApplying User-level Drivers on
Applying User-level Drivers on DTV System Gunho Lee, Senior Research Engineer, ELC, April 18, 2007 Content Background Requirements of DTV Device Drivers Design of LG DTV User-level Drivers Implementation
More informationLinux Kernel Development (LKD)
Linux Kernel Development (LKD) Session 1 Loadable Kernel Modules (LKM) Paulo Baltarejo Sousa pbs@isep.ipp.pt 2017 PBS LKD: S1 1 / 66 Disclaimer Material and Slides Some of the material/slides are adapted
More informationUniversity of Texas at Arlington. CSE Spring 2018 Operating Systems Project 4a - The /Proc File Systems and mmap. Instructor: Jia Rao
University of Texas at Arlington CSE 3320 - Spring 2018 Operating Systems Project 4a - The /Proc File Systems and mmap Instructor: Jia Rao Introduction Points Possible: 100 Handed out: Apr. 20, 2018 Due
More informationFormal Verification of Linux Device Drivers
Master s Thesis Formal Verification of Linux Device Drivers Thomas Witkowski May 2007 Supervisors: Prof. Dr. Daniel Kroening and Nicolas Blanc Contents 1. Introduction 7 1.1. Related Work...............................
More informationLinux Loadable Kernel Modules (LKM)
Device Driver Linux Loadable Kernel Modules (LKM) A way dynamically ADD code to the Linux kernel LKM is usually used for dynamically add device drivers filesystem drivers system calls network drivers executable
More informationRicardo Rocha. Department of Computer Science Faculty of Sciences University of Porto
Ricardo Rocha Department of Computer Science Faculty of Sciences University of Porto For more information please consult Advanced Programming in the UNIX Environment, 3rd Edition, W. Richard Stevens and
More informationADVANCED OPERATING SYSTEMS
ADVANCED OPERATING SYSTEMS UNIT 2 FILE AND DIRECTORY I/O BY MR.PRASAD SAWANT Prof.Prasad Sawant,Assitiant Professor,Dept. Of CS PCCCS Chichwad Prof.Prasad Sawant,Assitiant Professor,Dept. Of CS PCCCS Chichwad
More information20-EECE-4029 Operating Systems Fall, 2015 John Franco
20-EECE-4029 Operating Systems Fall, 2015 John Franco First Exam Question 1: Barrier name: a) Describe, in general terms, what a barrier is trying to do Undo some of the optimizations that processor hardware
More informationPCI Bus & Interrupts
PCI Bus & Interrupts PCI Bus A bus is made up of both an electrical interface and a programming interface PCI (Peripheral Component Interconnect) A set of specifications of how parts of a computer should
More informationRCU. ò Walk through two system calls in some detail. ò Open and read. ò Too much code to cover all FS system calls. ò 3 Cases for a dentry:
Logical Diagram VFS, Continued Don Porter CSE 506 Binary Formats RCU Memory Management File System Memory Allocators System Calls Device Drivers Networking Threads User Today s Lecture Kernel Sync CPU
More informationItron Riva Kernel Module Building
Itron Riva Kernel Module Building Table of Contents Introduction... 2 Creating the Project Directory... 2 Creating the Makefile... 3 Creating main.c... 5 Building The Kernel Module... 6 1 Introduction
More informationVFS, Continued. Don Porter CSE 506
VFS, Continued Don Porter CSE 506 Logical Diagram Binary Formats Memory Allocators System Calls Threads User Today s Lecture Kernel RCU File System Networking Sync Memory Management Device Drivers CPU
More informationLinux C C man mkdir( ) mkdir Linux man mkdir mkdir( ) mkdir mkdir( )
D Linux Linux E-D.1 Linux C C man mkdir( ) mkdir Linux man mkdir mkdir( ) mkdir mkdir( ) jhchen@aho:~$ man -S 2 mkdir Reformatting mkdir(2), please wait... MKDIR(2) Linux Programmer's Manual MKDIR(2) NAME
More informationCS 33. Files Part 2. CS33 Intro to Computer Systems XXI 1 Copyright 2018 Thomas W. Doeppner. All rights reserved.
CS 33 Files Part 2 CS33 Intro to Computer Systems XXI 1 Copyright 2018 Thomas W. Doeppner. All rights reserved. Directories unix etc home pro dev passwd motd twd unix... slide1 slide2 CS33 Intro to Computer
More informationCS 471 Operating Systems. Yue Cheng. George Mason University Fall 2017
CS 471 Operating Systems Yue Cheng George Mason University Fall 2017 1 Review: Sync Terminology Worksheet 2 Review: Semaphores 3 Semaphores o Motivation: Avoid busy waiting by blocking a process execution
More informationCMSC 216 Introduction to Computer Systems Lecture 17 Process Control and System-Level I/O
CMSC 216 Introduction to Computer Systems Lecture 17 Process Control and System-Level I/O Sections 8.2-8.5, Bryant and O'Hallaron PROCESS CONTROL (CONT.) CMSC 216 - Wood, Sussman, Herman, Plane 2 Signals
More informationLINUX DEVICE DRIVERS Weekend Workshop
Here to take you beyond LINUX DEVICE DRIVERS Weekend Workshop Linux Device Drivers Weekend workshop Objectives: To get you started with writing device drivers in Linux Provide real time hardware exposure
More informationLOCKDEP, AN INSIDE OUT PERSPECTIVE. Nahim El
LOCKDEP, AN INSIDE OUT PERSPECTIVE Nahim El Atmani @brokenpi_pe P1 R1 R1 P2 THE BIG PICTURE The need for a proof mechanism PREVIOUSLY ON LINUX SMP Synchronization needed giant-lock (a.k.a big-lock, kernel-lock
More informationInterprocess Communication. Originally multiple approaches Today more standard some differences between distributions still exist
Interprocess Communication Originally multiple approaches Today more standard some differences between distributions still exist Pipes Oldest form of IPC provided by all distros Limitations Historically
More informationFiles and Directories Filesystems from a user s perspective
Files and Directories Filesystems from a user s perspective Unix Filesystems Seminar Alexander Holupirek Database and Information Systems Group Department of Computer & Information Science University of
More informationI/O OPERATIONS. UNIX Programming 2014 Fall by Euiseong Seo
I/O OPERATIONS UNIX Programming 2014 Fall by Euiseong Seo Files Files that contain a stream of bytes are called regular files Regular files can be any of followings ASCII text Data Executable code Shell
More informationCSC369 Lecture 2. Larry Zhang
CSC369 Lecture 2 Larry Zhang 1 Announcements Lecture slides Midterm timing issue Assignment 1 will be out soon! Start early, and ask questions. We will have bonus for groups that finish early. 2 Assignment
More informationLogical disks. Bach 2.2.1
Logical disks Bach 2.2.1 Physical disk is divided into partitions or logical disks Logical disk linear sequence of fixed size, randomly accessible, blocks disk device driver maps underlying physical storage
More informationCSCI-E28 Lecture 3 Outline. Directories, File Attributes, Bits, File Operations. Write our own versions of Unix programs
CSCI-E28 Lecture 3 Outline Topics: Approach: Directories, File Attributes, Bits, File Operations Write our own versions of Unix programs Featured Commands: ls, ls -l Main Ideas: Adirectory is a list of
More informationCSC369 Lecture 2. Larry Zhang, September 21, 2015
CSC369 Lecture 2 Larry Zhang, September 21, 2015 1 Volunteer note-taker needed by accessibility service see announcement on Piazza for details 2 Change to office hour to resolve conflict with CSC373 lecture
More informationWorkspace for '5-linux' Page 1 (row 1, column 1)
Workspace for '5-linux' Page 1 (row 1, column 1) Workspace for '5-linux' Page 2 (row 2, column 1) ECEN 449 Microprocessor System Design Introduction to Linux 1 Objectives of this Lecture Unit Learn basics
More informationOrbix TS Thread Library Reference
Orbix 6.3.9 TS Thread Library Reference Micro Focus The Lawn 22-30 Old Bath Road Newbury, Berkshire RG14 1QN UK http://www.microfocus.com Copyright Micro Focus 2017. All rights reserved. MICRO FOCUS, the
More informationKernel Internals. Course Duration: 5 days. Pre-Requisites : Course Objective: Course Outline
Course Duration: 5 days Pre-Requisites : Good C programming skills. Required knowledge Linux as a User Course Objective: To get Kernel and User Space of Linux and related programming Linux Advance Programming
More informationOutline. OS Interface to Devices. System Input/Output. CSCI 4061 Introduction to Operating Systems. System I/O and Files. Instructor: Abhishek Chandra
Outline CSCI 6 Introduction to Operating Systems System I/O and Files File I/O operations File Descriptors and redirection Pipes and FIFOs Instructor: Abhishek Chandra 2 System Input/Output Hardware devices:
More information