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
output port register
timing signals
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 resourses isn’t assured
On Uniprocessor Systems
• Disable interrupts during “critical section”:
cli();
// do not recognize interrupts
…
/* critical code-fragment goes here */
…
sti();
// ok to recognize interrupts
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
Module ‘Boilerplate’
• Must have ‘init_module()’ function
(to ‘register’ service-functions with kernel)
• Must have ‘cleanup_module()’ function
(to ‘unregister’ your service-functions)
More ‘boilerplate’
• Must include certain kernel header-files
(e.g., #include <linux/module.h>)
• Must define certain constants
(e.g., #define __KERNEL__, MODULE)
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!