linux device drivers
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
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 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!