Linux device drivers
1 / 24

Linux Device Drivers - PowerPoint PPT Presentation

  • Updated On :

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Linux Device Drivers' - Angelica

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

What s a device driver l.jpg
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 drivers3 l.jpg
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:


Types of device drivers l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
‘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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg

Standard PC/AT Keyboard

Controlling the three LEDs

References on pc keyboard l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
“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 l.jpg
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 l.jpg
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 l.jpg
On Multiprocessor Systems

  • Not enough to block interrupts on one cpu

  • Must also insure other cpus can’t interfere

Module boilerplate l.jpg
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 l.jpg
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 l.jpg
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!