Linux Device Drivers: Inroduction

You might also like

Download as ppt, pdf, or txt
Download as ppt, pdf, or txt
You are on page 1of 27

Linux Device Drivers

Inroduction
What’s a ‘device-driver’?
• A special kind of computer program
• Intended to control a peripheral device
• Needs to execute ‘privileged’ instructions
• Must be integrated into the OS kernel
• Interfaces both to kernel and to hardware
• Program-format specific to a particular OS
Linux device-drivers
• A package mainly of ‘service functions’
• The package is conceptually an ‘object’
• But in C this means it’s a ‘struct’
• Specifically: struct file_operations { …; };
• Definition is found in a kernel-header:
‘/usr/src/linux/include/linux/fs.h’
Types of Device-Drivers
• Character drivers:
- the device processes individual bytes
(e.g., keyboard, printer, modem)

• Block drivers:
- the device processes groups of bytes
(e.g., hard disks, CD-ROM drives)
Linux has other driver-types
• Network drivers
• Mouse drivers
• SCSI drivers
• USB drivers
• Video drivers
• ‘Hot-swap’ drivers
• … and others
Linux treats devices as files
• Programmers accustomed to the file API
open(), seek(), read(), write(), close(), ...

• Requires creating a filename in a directory


(special ‘/dev’ directory is for devices)
Driver Identification
• Character/Block drivers:
• Use ‘major-number’ to identify the driver
• Use ‘minor-numbers’ to distinguish among
several devices the same driver controls
• Kernel also needs a driver-name
• Users need a device-node as ‘interface’
Developing a device-driver
• Clarify your requirements
• Devise a design to achieve them
• Test your design-concept (‘prototype’)
• ‘Debug’ your prototype (as needed)
• Build your final driver in iteratively
• Document your work for future use
‘Open Source’ Hardware
• Some equipment manufactures regard
their designs as ‘intellectual property’
• They don’t want to ‘give away’ their info
• They believe ‘secrecy’ is an advantage
• They fear others might copy their designs
• BUT: This hinders systems programmers!
Non-Disclosure Agreements
• Sometimes manufacturers will let ‘trusted’
individuals, or commercial ‘partners’, look
at their design-specs and manuals.
• College professors usually are ‘trusted’
• BUT: Just to be sure, an NDA is required
-- which prevents professors from teaching
students the design-details that they learn.
Advantage of ‘open’ designs
• Microsoft and Apple used to provide lots
of technical information to programmers.
• They wanted to encourage innovations
that made their products more valuable.
• Imagine hundreds of unpaid ‘volunteers’
creating applications for your system!
• BUT: Were they ‘giving away the store’?
Some designs are ‘open’
• The IBM-PC designs were published
• Other companies copied them
• And those companies prospered!
• While IBM lost market-share!
• An unfortunate ‘lesson’ was learned
Standard PC/AT Keyboard

Controlling the three LEDs


References on PC keyboard
• Hans-Peter Messmer, “The Indispensable
PC Hardware Book (Third Edition)”,
Addison-Wesley (1997), pp. 1007-1030.

• Frank van Gilluwe, “The Undocumented


PC (Second Edition)”, Addison-Wesley
(1997), pp. 309-390.
8042 Keyboard Controller
• Programming Interface (4 registers):
control register (0x64, write-only)
status register (0x64, read-only)
input buffer register (0x60, write-only)
output buffer register (0x60, read-only)
• Device Interface (2 registers + 2 signals):
input port register timing signals
output port register interrupt signals
Keyboard Controller’s Status
• Eight individual status-bits (read-only)
• Visible to cpu by using: ‘inb( 0x64 );
bit #0: output-buffer full
bit #1: input-buffer full
• Other bits are unimportant for LEDs
Two-Step Sequence
• Step 1: Send command-byte
• Step 2: Send parameter-byte

• If this sequence were to interrupted, then


another process might try to send a byte,
causing hardware to perform wrong action!
“Critical Section”
• Code-fragment whose correct functioning
depends on it not being interrupted
• Subject to “race conditions” if exclusive
access to resources isn’t assured
On Uniprocessor Systems ver 2.4
• Disable interrupts during “critical section”:

cli(); // do not recognize interrupts



/* critical code-fragment goes here */

sti(); // ok to recognize interrupts
On Multi-processor Systems ver 2.6
• In the 2.6 kernel, it is no longer possible to
globally disable interrupts
– Kernel 2.6 is pre-emptible means that kernel
code can be interrupted at (almost) any time
• protection of critical sections is done by
spin locks
– A spin lock works through a shared variable.
– Any function needing the lock will query it and,
seeing that it is not available, will "spin" in a
busy-wait loop until it is available
Spinlocks
• Spinlocks can be imagined as
– while(turn != processor_id);
• No other process can hold the processor
• Pre-emption is disabled on spin locks
• Avoid sleeping on a spin lock
• Interrupts still work on normal spinlock
• It is possible to hang the entire system on a
spin lock
Spinlocks
• spin_lock_irqsave(spinlock_t *lock, unsigned long flags)
– not only the lock is acquired but also all
interrupts on the local processor are disabled
and the current interrupt state is stored in flags.
• spin_unlock_irqrestore(spinlock_t *lock, unsigned long flags)
– unlocks the given lock and enables interrupts
(depending on the flags value).
Algorithm for setting LEDs
• Block interrupts (Enter “Critical Section”)
• Wait till controller’s input-buffer empties
• Output the ‘write_LED’ command-byte
• Wait till controller’s input-buffer empties
• Output the LED indicator-byte
• Wait till controller’s input-buffer empties
• Allow interrupts (Leave “Critical Section”)
On Multiprocessor Systems
• Not enough to block interrupts on one cpu
• Must also insure other cpus can’t interfere
• Kernel ver 2.6 is now pre-emptible
Module ‘Boilerplate’
• Must have ‘init’ function
(to ‘register’ service-functions with kernel)

• Must have ‘cleanup’ function


(to ‘unregister’ your service-functions)
More ‘boilerplate’
• Must include certain kernel header-files
(e.g., #include <linux/module.h>
#include<linux/init.h>)

• Must define certain constants


(e.g., #define __KERNEL__, MODULE)
(This is not present for Ver 2.6)
Rapid Prototyping
• We will be writing lots of modules
• We can ‘automate’ the boilerplate
• We should write a ‘wizard’ program
• It will save us LOTS of time!

You might also like