Driver functions

A naming convention established early on in the life of the UNIX operating system helps keep the names of driver functions consistent. A short driver identification (it used to be only two characters long, but that has expanded over time) is attached to the basic name of the function. Thus we have routines like:

• stopen() ” Handles an open request on a SCSI tape drive

• sdread() ” Performs a SCSI disk read

• idwrite() ” Writes to IPI disks

• ptcioctl() ” Interprets ioctl requests on pseudo-terminals

• cg6_poll() ” Checks the CG-6 frame buffer

• fdstrategy() ” Sets up floppy disk I/O requests

• zsintr() ” Responds to serial character interrupt requests

Each driver has some standard routines which it must provide, and these are easily recognizable in stack traces. They serve the following functions, among others.

• open() ” For a user open request

• close() ” Called on the last user close request

• read() ” Handles a read system call

• write() ” Processes a write system call

• strategy() ” Used for disk requests (block devices only)

• ioctl() ” Sends special requests or commands to the driver

• mmap() ” For devices capable of being mapped into memory

• probe() ” Determines whether the device is present

• attach() ” Called after probe returns true, finishes setting up the device

• intr() ” Handles interrupt requests

All these names will appear in most drivers for both SunOS 4.x and Solaris 2 systems. The actual function name you see in a stack traceback will, of course, be prefaced with the name of the device, such as sdopen() for an open function in the sd (SCSI disk) driver code.

Identifying driver functions involved in a panic or hang situation may help to isolate the problem. If a user-level (or top half) function is involved, the driver may be invoking kernel support routines with bad parameters or setting up data incorrectly for these functions to use. An interrupt service routine appearing in the traceback could indicate problems with the device hardware itself, data structures that were not correctly set up for an interrupt to reference, or possibly an error in locking (a race condition). Drivers are very complex, and it's easy to miss a small requirement that has drastic implications later on. While it's certainly not always true that driver code in a traceback automatically indicates a driver problem, it may be worth checking to see if the problem only occurs when the device is in use.