Linux device drivers
Download
1 / 24

Linux Device Drivers - PowerPoint PPT Presentation


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

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

Download Presentation

Linux Device Drivers

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


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 registertiming signals

    output port registerinterrupt 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!


ad
  • Login