Devices and Drivers (Chapter 7) - PowerPoint PPT Presentation

About This Presentation
Title:

Devices and Drivers (Chapter 7)

Description:

Devices and Drivers (Chapter 7) Khattab Alhabashi UNIX System Administration Introduction Definition: A device driver is a program that manages the system s ... – PowerPoint PPT presentation

Number of Views:87
Avg rating:3.0/5.0
Slides: 18
Provided by: kalh
Category:

less

Transcript and Presenter's Notes

Title: Devices and Drivers (Chapter 7)


1
Devices and Drivers (Chapter 7)
  • Khattab Alhabashi
  • UNIX System Administration

2
Introduction
  • Definition A device driver is a program that
    manages the systems interaction with a
    particular piece of hardware.
  • The driver translates between the hardware
    commands understood by the device and the
    stylized programming interface used by the
    kernel.
  • The existence of the driver layer helps to keep
    UNIX reasonably device-independent.
  • Device drivers are part of the kernel they are
    not user processes. However, a driver can be
    accessed both from within the kernel and from
    user space.
  • User-level access to devices is provided through
    special device file that live in the /dev
    directory.

3
Introduction Contd.
  • Most devices in the system will fall into three
    categories
  • 1) SCSI
  • Devices that attach to a SCSI bus are easy to
    configure.
  • Most systems have one driver that allows direct
    access to the SCSI bus, plus additional drivers
    for special types of devices such as disks and
    tapes.
  • 2) Vendor
  • Most devices you can buy from your hardware
    vendor will already be supported by the operating
    system.
  • Unless you have explicitly removed drivers, the
    kernel will usually recognize a new device as
    soon as you install it.
  • The appropriate device files in /dev will already
    have been created for you, or the OS will create
    them on the fly.

4
Introduction Contd.
  • 3) Third-party
  • When you purchase a piece of hardware from a
    third party (someone other than your hardware
    vendor), it will usually come with an
    installation script that installs the device,
    configures the kernel if necessary, and makes
    devices entries.
  • On systems with loadable drivers, kernel
    configuration may not be necessary.

5
Device Numbers and Jump Tables
  • Device files are mapped to devices via their
    major and minor device numbers, values that are
    stored in the files inode structure.
  • The major device number identifies the driver
    that the file is associated with.
  • The minor device number identifies which
    particular device of a given type is to be
    addressed. It is often called the unit number or
    instance of the device.
  • There are two types of device files
  • Block device files it is read or written a block
    (a group of bytes, usually multiple of 512) at a
    time.
  • Character device files it can be read or written
    one byte at a time.

6
Device Numbers and Jump Tables Contd.
  • Some devices support access via both block and
    character device files.
  • Each driver has routines for performing some or
    all of the following functions
  • probe attach open
    close read reset stop
  • select strategy dump
    psize write timeout
  • process a transmit interrupt
  • process a receive interrupt
  • ioctl (input / output control)
  • Inside the kernel, the addresses of these
    functions for each driver are stored in a
    structure called a jump table.

7
Device Numbers and Jump Tables Contd.
  • There are actually two tables
  • - One for character device and
  • - One for block devices.
  • The jump tables are indexed by major device
    numbers.
  • When a program performs an operation on a device
    file, the kernel automatically catches the
    reference, looks up the appropriate function name
    in the jump table, and transfers control to it.
  • To perform an unusual operation that doesnt have
    a direct analog in filesystem model (for example,
    ejecting floppy disk), the ioctl system call is
    used to pass a message directly from user space
    into the driver.

8
Device Numbers and Jump Tables Contd.
  • Three examples were discussed in this chapter
    about adding device drivers
  • - Adding a BSD Device Driver Adding a
    completely new device driver to BSD machine
    involves adding it to a couple of configuration
    files and editing the kernel source code to
    include references to the drivers routine.
  • - Adding an HP-UX Device Driver On HP-UX
    systems, the jump tables are constructed from
    specifications in a text file called master.
  • - Adding an IRIX Device Driver IRIX uses a
    directory of files (/var/sysgen/master.d) to
    perform the same function as the single master
    file in HP-UX.

9
Device Numbers and Jump Tables Contd.
  • There are some common steps in all three examples
    that have to be done after adding and modifying
    the files specified for each example
  • - Building a new kernel.
  • - Copying the old kernel aside and installing
    the new kernel.
  • - Rebooting and testing the new kernel.
  • - Creating device files and test the device
    itself.

10
Device Files
  • By convention, device files are kept in the /dev
    directory.
  • ATT systems handle device files quite nicely by
    using separate subdirectory of /dev for each
    type of device
  • disk, tape, terminal, etc.
  • Device files are created with the mknod command,
    which has the syntax
  • mknod filename type major minor
  • where
  • - filename is the device file to be created.
  • - type is c for a character device or b for a
    block device.
  • - major and minor are the major and minor
    device numbers.

11
Device Files Contd.
  • A shell script called MAKEDEV is sometimes
    provided (in /dev) to automatically supply
    default values to mknod.
  • You need to scan through the script to find the
    arguments needed for your device. For example,
    to make PTY entries on a SunOS system, you would
    use the following command
  • cd /dev
  • ./MAKEDEV pty

12
Naming Conventions For Devices
  • Devices that have both block and character
    identities usually
  • - preface the character device name with the
    letter r for row (e.g.,
    /dev/sd0 and /dev/rsd0), or
  • - place it in a subdirectory with a name that
    starts with r
  • (e.g., /dev/dsk/dks0d3s0 vs. /dev/rdsk/dks0d3s0)
    .
  • Serial devices are usually named tty followed by
    a sequence of letters that identify the interface
    the port is attached to (See chapter 8 for more
    information
  • about serial ports).


13
Naming Conventions For Devices Contd.
  • BSD disk names often begin with a two-letter
    abbreviation for either the drive of the
    controller, followed by the drive number and
    partition name.
  • - Example sd0a is the block device
    representing the partition of the first disk
    drive on a SCSI controller rsd0a is the
    corresponding character device.
  • The names of tapes and devices often include not
    only a reference to the drive itself, but also an
    indication of whether the device rewinds after
    each tape operation and the density at which it
    reads and writes.

14
Loadable Kernel Modules
  • Loadable modules allow device drivers to be
    linked into and removed from the kernel while it
    is running.
  • - This makes the installation of drivers much
    easier, since the kernel binary does not have to
    be changed.
  • - It also allows the kernel to be smaller,
    because drivers are not loaded unless they are
    needed.
  • Loadable modules are implemented by providing one
    or more documents hooks into the kernel where
    additional device drivers can grab on.
  • A user-level command communicates with the kernel
    and tells it to load new modules into memory and
    to make entries for them in the systems jump
    tables.

15
Loadable kernel Modules Contd.
  • Although loadable drivers are convenient, they
    are not entirely safe.
  • Any time you load or unload a module, you risk
    causing a kernel panic.
  • Like other aspects of device and driver
    management, the implementation of loadable
    modules is operating system dependent.
  • There are four of the example systems that
    support loadable modules
  • - Solaris In Solaris, virtually everything is
    a loadable module. The modinfo command lists the
    currently-loaded modules. You can add a driver
    with the add_drv command.

16
Loadable Kernel Modules Contd.
  • - HP-UX Generic HP-UX does not support
    loadable modules, but there is an option that
    allows the loading of STREAMS modules.
  • - IRIX IRIX 5.2 supports loadable modules
    earlier versions did not. Modules are
    manipulated with the ml command. ml with the
    list option catalogs the modules that the kernel
    is currently aware of.
  • - SunOS SunOS versions 4.1.2 and later
    contain support for loadable modules.
    Currently-loaded modules can be listed with
    modstat.

17
  • END OF CHAPTER
  • QUESTIONS???
Write a Comment
User Comments (0)
About PowerShow.com