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 system’s 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 file’s 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 doesn’t 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 driver’s 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: mknodfilename 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 system’s 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???