Sogang University Advanced Operating Systems (Enhanced Device Driver Operations) Advanced Operating Systems (Enhanced Device Driver Operations) Sang Gue Oh, Ph.D.

Sogang University Enhanced Device Driver Operations Page 2 Introduction Introduction n Controlling the hardware using ioctl t delivers commands to the device other than read/write. l adjusting baud rate, … Blocking I/O t puts the requesting process in wait state (e.g., sleep_on(), etc). t the kernel may schedule other process (e.g., schedule(), etc). t why? the kernel cannot be preempted and the device takes time to process the request. n Interrupt Handling

Sogang University Enhanced Device Driver Operations Page 3 Controlling the Hardware using ioctl Controlling the Hardware using ioctl n ioctl is a system call with 3 arguments int ioctl(int fd, int cmd, … ); t the 3 rd argument is optional (argument for the command). n Inside kernel int (*ioctl) (struct inode *inode, struct file filp, unsigned int cmd, unsigned long arg); t Since type checking is disabled on the extra argument, the compiler can’t warn if an invalid argument is passed to ioctl (3 rd argument). t The programmer won’t notice the error until run time. n Command is an integer t You may define meaningful names in the header file. t The command numbers should be unique across the system to prevent errors caused by issuing the right commands to the wrong device.

Sogang University Enhanced Device Driver Operations Page 4 Choosing the ioctl Commands Choosing the ioctl Commands n The commands generally consist of four bit-fields t type (magic number) : used throughout the driver. t number : ordinal number to denote a device. t direction : no data, read (from device), write (to device). t size : size of data transfer involved (pass the instance without sizeof). n Macros to encode/decode a command (defined in ) t Encoding l _IO(type, number) : for no data transferring command l _IOR(type, number, size) : for read l _IOW(type, number, size) : for write l _IOWR(type, number, size) : for read and write t Decoding four bit-fields l _IOC_TYPE(command), _IOC_NR(command) l _IOC_DIR(command), _IOC_SIZE(command)

Sogang University Enhanced Device Driver Operations Page 5 Blocking I/O n What if there is no data ready for read ? t go sleep waiting for the data n Go to sleep t void interruptible_sleep_on(struct wait_queue **q); l a signal can abort the sleep t void sleep_on(struct wait_queue **q); n Wake up t void wake_up_interruptible(struct wait_queue **q); t void wake_up(struct wait_queue **q); n One wait queue for each event t E.g., one for read and one for write for each device

Sogang University Enhanced Device Driver Operations Page 6 Writing Reentrant Code Writing Reentrant Code n When a process is put to sleep, the driver is still alive and can be called by another process. n Such situations can be handled by writing “reentrant code”. n Reentrant code t for processes that can be on sleep t all blocking functions and functions that call them t need to store state information for each process n Where to put the state information ? t filp->private_data l works only when one process uses the file t local static variable in the driver l each process has its own stack l use kmalloc if large space is needed

Sogang University Enhanced Device Driver Operations Page 7 Asynchronous Operations – Interrupt Handling Asynchronous Operations – Interrupt Handling n Installing/Freeing an Interrupt Handler t int request_irq(unsigned int irq, void (*handler)(int, void*, struct pt_regs*), unsigned long flags, const char *device, void *dev_id ); l irg : interrupt number. l handler : pointer to the handling function being installed. l flag : bit-mask of options related to interrupt management. –SA_INTERRUPT : set when “fast” interrupt. Cleared when “slow” interrupt. –SA_SHIRQ : interrupt can be shared between devices. l device : string used in /proc/interrupts to show the owner. l device_id : usually set to NULL. Used only for shared interrupt. t void free_irq(unsigned int irq, void *dev_id);

Sogang University Enhanced Device Driver Operations Page 8 Example of Installing an Interrupt Handler Example of Installing an Interrupt Handler n Short Interrupt Handler IRQ Requesting Example If ( short_irq >= 0 ) { request = request_irq(short_irq, short_interrupt, SA_INTERRUPT, “short”, NULL ); if ( request ) { /* return 0 if successful */ printk( KERN_INFO “cannot be assigned irq %I\n”, short_irq ); short_irq = -1; } else { outb( 0x10, short_base + 2 ); }

Sogang University Enhanced Device Driver Operations Page 9 Initializing an Interrupt Handler Initializing an Interrupt Handler n Init module time t Sounds like a good idea but it actually isn’t. t If a module requests an IRQ at initialization, it prevents any other driver from using the interrupts, even if the device holding it is never used. n Device open time t The correct place to call request_irq is when the device is first opened, before the hardware is instructed to generate interrupts. t The place to call free_irq is the last time the device is closed, after the hardware is told not to interrupt the processor any more.

Sogang University Enhanced Device Driver Operations Page 10 Statistics for Interrupts (/proc/interrupt) Statistics for Interrupts (/proc/interrupt) IRQ # IRQ #(installed) Interrupt count count

Sogang University Enhanced Device Driver Operations Page 11 Low-Level Statistics for Interrupts (/proc/stat) Low-Level Statistics for Interrupts (/proc/stat) Total # of all interrupts Interrupt 0 count Interrupt 1 count ……….

Sogang University Enhanced Device Driver Operations Page 12 Assigning an IRQ Number Assigning an IRQ Number if ( short_irq < 0 ) { switch ( short_base ) { case 0x378: short_irq = 7; break; case 0x278: short_irq = 2; break; case 0x3bc: short_irq = 5; break; } insmod short short_irq = x [enter]

Sogang University Enhanced Device Driver Operations Page 13 Probing (Kernel-Helped Probing) Probing (Kernel-Helped Probing) int count = 0; do { unsigned long mask; mask = probe_irq_on(); outb_p(0x10, short_base + 2);// Enable reporting outb_p(0x00, short_base);// Clear bits outb_p(0xff, short_base);// Set the bit: Interrupt outb_p(0x00, short_base + 2);// Disable reporting short_irq = probe_irq_off(mask); if ( short_irq == 0 ) { /* return 0 if no interrupt, otherwise return interrupt #, return negative if more than one interrupt occurred */ printk( KERN_INFO “No irq reported by probe.\n” ); short_irq = -1; } } while ( short_irq < 0 && count++ < 5 );

Sogang University Enhanced Device Driver Operations Page 14 Probing (Do-It-Yourself Probing) (1) Probing (Do-It-Yourself Probing) (1)

Sogang University Enhanced Device Driver Operations Page 15 Probing (Do-It-Yourself Probing) (2) Probing (Do-It-Yourself Probing) (2)

Sogang University Enhanced Device Driver Operations Page 16 Probing (Do-It-Yourself Probing) (3) Probing (Do-It-Yourself Probing) (3)

Sogang University Enhanced Device Driver Operations Page 17 Fast and Slow Handlers Fast and Slow Handlers n What is the difference? t The main difference between the two kinds of interrupt handlers is that fast handlers guarantee atomic processing of interrupts and slow interrupts don’t. t While a slow handler is invoked, on the other hand, the kernel re- enables interrupt reporting in the microprocessor, so other interrupts can be serviced while a slow handler runs. t A fast handler runs with interrupt reporting disabled in the microprocessor, and the interrupt being serviced is disabled in the interrupt controller. The handler can nonetheless enable reporting in the processor by calling sti. t A slow handler runs with interrupt reporting enabled in the processor,and the interrupt being serviced is disabled in the interrupt controller.

Sogang University Enhanced Device Driver Operations Page 18 Example of a Short Interrupt Handler Example of a Short Interrupt Handler n The role of an interrupt handler is to give feedback to its device about interrupt reception and to read or write data according to the meaning of the interrupt being serviced. Interrupt number Snapshot of the processor’s context Usually 0 but can be used to pass arguments

Sogang University Enhanced Device Driver Operations Page 19 Bottom Halves (1) Bottom Halves (1) n One of the main problems with interrupt handling is how to perform longish tasks within a handler. n Split the handler into two halves: “top half” and “bottom half”. t Top half is the routine you register through request_irq. t The bottom half (“bh” for short) is a routine that is scheduled by the top half, to be executed later, at a safer time. n In the typical scenario, the top half saves device data to a device- specific buffer, marks its bottom handler, and exits. The bh then dispatches newly arrived data to the processes, awakening them if necessary. n Network processing: when a network interface reports the arrival of a new packet, the handler just retrieves the data and pushes it up to the protocol layer; actual processing of the packet is performed in a bottom half.

Sogang University Enhanced Device Driver Operations Page 20 Bottom Halves (2) Bottom Halves (2) n The bottom halves exist as an array of 32 function pointers and a bit-mask. Once a bottom half handler is activated, it is executed when do_bottom_half function is invoked, which happens within ret_from_sys_call. The ret_from_sys_call is executed whenever a process exits from a system call or when a slow interrupt handler exits. n That is, after every ret_from_sys_call, a list of up to 32 bottom halves is scanned. If they are marked active, they are each carried out once in turn and then automatically marked as inactive.

Sogang University Enhanced Device Driver Operations Page 21 Install and Activate a Bottom Half handler Install and Activate a Bottom Half handler n Whenever some code wants to schedule a bottom half for running, it calls mark_bh, which sets a bit in the bit-mask variable to queue the corresponding function for execution. #include void mark_bh(int nr); -> nr is the # of the bh to activate n The function to install a bottom half is init_bh which enters the bottom half into the function pointer table. void init_bh(int nr, void (*routine)(void)); n The function that corresponds to each bh is provided by the driver that owns the bottom half. t For example, when mark_bh(KEYBOARD_BH) is called, the function being scheduled for execution is kbd_bh, which is part of the keyboard driver.

Sogang University Enhanced Device Driver Operations Page 22 Pre-Defined Bottom Halves Pre-Defined Bottom Halves n IMMEDIATE_BH t Use tq_immediate task queue. A driver that doesn’t own a bottom half can use the immediate queue as if it were its own bh. Need to call mark_bh to execute the code. n TQUEUE_BH  Use tq_timer task queue. Activated at each timer tick. No need to call mark_bh. TQUEUE_BH is always executed later than IMMEDIATE_BH. n NET_BH  Network drivers should mark this queue to notify the upper network layers of events. n TIMER_BH t Marked by do_timer, the function in charge of the clock tick.

Sogang University Enhanced Device Driver Operations Page 23 Example of a Top Half Example of a Top Half Task queue structure

Sogang University Enhanced Device Driver Operations Page 24 Example of a Bottom Half (1) Example of a Bottom Half (1)

Sogang University Enhanced Device Driver Operations Page 25 Example of a Bottom Half (2) Example of a Bottom Half (2)