Devices and Drivers

This contains links to information used in the lectures.

Device drivers are parts of the Unix kernel that manage interaction with particular types of hardware. The device driver translates device independant kernel directives to device dependant hardware commands. In 1980s each device had an interface board and a custom driver, which had to be compiled into the kernel. This has simplified as follows:

Workstation manufacturers include many drivers that used to be optional in standard configurations.
Many systems now check automatically for installed devices and add the appropriate drivers.
Most disks and tapes use the SCSI standard, rather than proprietary interfaces.
Some systems support loadable kernel modules which are loaded dynamically to the kernel without relinking it.

Adding new devices is usually easy since they are usually

SCSI and use the existing driver
vendor supplied with driver in kernel unless removed explicitly.
Third party with an installation script which installs drivers, reconfigures the kernel, and makes device entries.

The following indicate the steps in the process in case one does it by hand.

Device Numbers and Jump Tables

Devices files in /dev are mapped to devices using major and minor device numbers - major gives device driver, minor individual device of that type. There are are two types of device:

Block - kernel performs buffering, written in blocks usually multiple of 512 bytes.
Character - raw unbuffered in kernel

Disks and tapes have both, terminals and serial printers have only character. The device drivers provide routines for standard operations such as:

probe	attach	open	close	read 	reset	stop
select	strategy	dump	psize	write	timeout

process a transmit interrupt
process a receive  interrupt
ioctl

The addresses of these are stored in jump tables in the kernel indexed by major device number (usually one for character devices and one for block). The kernel uses the jump table to determine the device specific function to transfer control to. For operations, such as floppy ejection, which have no analogues in the general filesystem model, the ioctl call is used to pass the message dircetly to the device.

Abstract or pseudo devices

Used, for example, to provide pseudo-terminal devices to users logged in over the network.p

Adding Entries to Jump Tables

This used to be done by editing the source. Now usually built from text files. There is usually also a file which determines the modules linked into the kernel.

HP-UX 9.XX	/etc/master		/etc/conf/dfile	
HP-UX 10.XX	/usr/conf/master.d/*	/stand/system
SunOS (Nimitz)	/usr/share/sys/sun4m/conf/KERNEL   /usr/share/sys/sun4m/conf/files

KERNEL is GENERIC, GENERIC_SMALL, DLmodel, SDSTmodel, etc. On SunOS do man config, and on HP-UX, man config, man master and man uxgen.

HP-UX 9.XX - adding a device driver

The jump tables are constructed from specification in /etc/master. Software drivers are defined as follows:

Field 1        Device name, used in the user-specified dfile (8
	       characters maximum).

Field 2        Handler name, used by the kernel to prefix
	       routines such as cs80_read, lp_write, and others
	       (8 characters maximum).

Field 3        Element characteristics: Five bits make up the
	       mask
           Bit 1:  card
           Bit 2:  specified only once
           Bit 3:  required driver
           Bit 4:  block device
           Bit 5:  character device (LSB)

Field 4        Functions for the device; 12 bits make up the mask
           Bit 1   option1 handler (Series 700 only)
           Bit 2   dump handler
           Bit 3   size handler
           Bit 4   link routine
           Bit 5   open handler
           Bit 6   close handler
           Bit 7   read handler
           Bit 8   write handler
           Bit 9   ioctl handler
           Bit 10  select handler
           Bit 11  seltru handler
           Bit 12  C_ALLCLOSES flag (LSB)

Field 5        Major device number if a block-type device;
	       otherwise -1.

Field 6        Major device number if a character-type device;
	       otherwise -1.

Note that bit 1 is the most significant bit.

If the device does not exist in the kernel configuration file dfile, it is not compiled into the kernel.

After the predefined device there are a number of entries reserved for third party use.

** Reserved for Third Party and User Drivers.
*               ---             -       -       -1      38
*               ---             -       -       -1      39
*               ---             -       -       -1      40
*               ---             -       -       -1      41
*               ---             -       -       -1      42
*               ---             -       -       -1      43
*               ---             -       -       8       -1
*               ---             -       -       15      -1
*               ---             -       -       16      -1
*               ---             -       -       17      -1
*               ---             -       -       18      -1

Later library dependencies are defined in a driver/library table. This table defines which libraries a given driver depends on. If the driver is included in the dfile, then the libraries that driver depends on will be included on the ld(1) command line. Only optional libraries *need* to be specified in this table, (but required ones can be included, as well).

* Driver handle    
*
* subsystems first 
netware         libnetware.a
uipc            libuipc.a
nipc            libuipc.a libnipc.a libinet.a
nit             libnit.a libnet.a
inet            libinet.a libnet.a
ni              libnet.a libinet.a

Note that if one is adding a compiled driver, one must create a library from the .o file by using ar and then copy it to the /etc/conf. One must also add the device name to the dfile in /etc/conf.

HP-UX 10.XX - adding device files

In HP-UX 10.XX the master file has been replaces by a set of files in /usr/conf/master.d and the dfile has been moved to /stand/system. The format of thefiles in /usr/conf/master.d is somewhat different from that of master under HP-UX 9.XX (see for example core-hpux and lan.

Making device files

By convention device files are in /dev. ATT uses separate subdirectories for each device type : disk, tape etc. HP-UX has some in the main directory and some on subdirectories such as dsk, pts, pty, ptym, rdsk, etc.

Device files are created using mknod:

mknod name type major minor

name is the path name of the file to be created. The newly created file has a default mode that is readable and writable by all users (066), but the mode is modified by the current setting of the user's file mode creation mask (see umask(1)).
type is either c for character or b for block device.
major The major number specifies the major device type (for example, the device driver number).
minor The minor number specifies the device location, which is typically, but not always, the unit, drive, HP-IB bus address and/or line number.

Note that one should check the device manual for the correct major and minor device numbers.

Some systems such as SunOS supply a script MAKEDEV in /dev to automatically supply default values to mknod.

Naming Conventions for Devices

These vary a lot. Usually devices with both character (raw) and block modes differ by the raw having an r prefix either on the file or dircetory name, for example, SCSI disk on HP-UX and SunOS

crw-r-----   1 root     sys       47 0x201000 Dec  1  1993 /dev/rdsk/c201d0s0
crw-r-----   1 root     sys       47 0x201100 Apr  2  1993 /dev/rdsk/c201d1s0
brw-r-----   1 root     sys        7 0x201000 Dec  1  1993 /dev/dsk/c201d0s0
brw-r-----   1 root     sys        7 0x201100 Apr  2  1993 /dev/dsk/c201d1s0

crw-r-----  1 root      17,   8 Feb 18  1994 /dev/rsd1a
crw-r-----  1 root      17,   9 Nov  5  1992 /dev/rsd1b
brw-r-----  1 root       7,   8 Nov  5  1992 /dev/sd1a
brw-r-----  1 root       7,   9 Nov  5  1992 /dev/sd1b

where the format is /dev/dsk/c201dNsP and /dev/sdNP, where N is unit and P the partition respectively.

Serial device usually have the form /dev/tty followed by a sequence of letter which identify the port it is attached to:

crw-rw-rw-   2 root     other     17 0x000020 Apr  2  1993 /dev/ttyr0
crw-rw-rw-   2 root     other     17 0x000021 Apr  2  1993 /dev/ttyr1

Can be more than one device per physical port.

Loadable Modules

Loadable modules allowed device drivers to be linked into the kernel while it is running. This removes the drivers from the kernel making it smaller. Most systems (but not HP-UX other than STREAMS modules in 10.XX) support loadable modules.

In SunOS modstat lists modules and modload and modunload load and unload them. To use loadable modules VDDRV must be included in the kernel configuration file and /dev/vd must exist.

In Solaris, most devices are loadable modules. modinfo lists modules, add_drv adds a driver, and rem_drv removes one. modload and modunload load and unload modules not accessed through device files.

Paul A. Farrell
Thu Feb 15 01:16:46 EST 1996