Entry Points

Drivers are accessed in three ways

• through system initialization

• through system calls from user programs

• through device interrupts

When the system is initialized, several tables are created so that the system can activate the correct driver routine. Because the system uses these tables to deter-mine the appropriate driver routines to enter, the routines themselves are some-times referred to as driver entry points.

Each table is associated with a specific set of entry-point routines. Initialization tables are associated with either init(D2D) or start(D2DK) routines. System calls use a pair of switch tables whose entry points include open(D2DK),

close(D2DK), read(D2DK), write(D2DK), and ioctl(D2DK) routines (for char-acter drivers), and open, close, and strategy(D2DK) routines (for block drivers).

STREAMS drivers are entered initially through the character switch table, but their open, close, put(D2DK), and srv(D2DK) routines are accessed indirectly through a chain of pointers to other structures. Device interrupts are associated with their appropriate interrupt handling routine through an interrupt vector table. The entry point is the intr(D2D) routine.

This section discusses these system tables and their associated entry points in greater detail.

Initialization Entry Points

Boths kinds of driver initialization routines (init and start) are executed during system initialization, in a different order each time the system is configured. The system uses the routines and information from the driver's configuration files to initialize the drivers. Information such as the major/minor numbers, important when accessing driver switch table entry points, is not used to initialize a driver.

The system does not differentiate between character- and block-access drivers when running the initialization routines.

The system initialization program first creates two internal tables, io_init and io~start, which it uses to list the routines that must be executed. After the sys-tem is initialized, the io_init and io_start tables are not accessed again. Not

1-14 Introduction to Device Drivers

all drivers need initialization routines. A driver that does not have an init or start routine has no entry in the io_init or io_start table.

Switch Table Entry Points

Two operating system switch tables, cdevsw and bdevsw, hold the entry-point routines for character and block drivers, respectively. These routines are activated by I/O system calls (Figure 1-3).

Figure 1-3: Switch Table Entry Points and System Calls

open close

Character Device Switch Table

I I I

Block Device Switch Table

I

I

t

f

t

Device

I

The process of calling the appropriate driver routine can be summarized as fol-lows

1. The I/O system call (open and read, for example) is directed to a special device file.

2. The special device file includes the major number for the driver that con-trols the device.

3. If the special device file is for block access, the system uses the major number as an index into the bdevsw table to find the appropriate routine.

For character access, the operating system looks in the cdevsw table, using the same method.

4. The operating system calls the appropriate routine.

Whenever the character (or block) entry points are being used, the other entry points are inaccessible. When the driver does a character-access read or write operation on a device that supports both block and character access, it calls the strategy routine. The driver calls the strategy routine, however, as a subordi-nate routine to read or write, not as the bdevsw entry point.

STREAMS drivers, although they use the cdevsw table, do not use the usual entry points. Instead, a STREAMS driver is recognized by a non-null value in the d_str field of cdevsw, which is a pointer to a streamtab(D4DK) structure. The stream-tab structure contains pointers to other structures which eventually point to STREAMS entry points.

Although the bdevsw and cdevsw tables have places for all possible driver rou-tines, not all routines are appropriate for all devices. For instance, a printer driver does not need a read routine. The operating system provides place holders in the switch tables for routines that are not included in the driver. The place holder routines are named nulldev and nod.ev. nulldev is an empty routine that is called when the routine it represents is not needed (for example, a halt routine for a printer driver would not be needed because it would have no work to do).

nodev is a routine that returns an error code when the routine it represents is called (for example, a read routine for a printer driver would create an error con-dition).

Interrupt Entry Points

The operating system must handle many kinds of system interrupts (such as clock and software interrupts), system exceptions (such as page faults), and interrupts from peripheral devices controlled by drivers. Interrupts cause the processor to stop its current process and to immediately begin to service the interrupt. Peri-pheral devices generate interrupts when an I/O transfer encounters an error or completes successfully.

When an interrupt is received from a hardware device, the kernel determines the interrupt vector number of the device and passes control to the appropriate driver's interrupt handling routine(s). It does this by accessing the interrupt vec-tor table, populated during system initialization. The interrupt handler must

1-16 Introduction to Device Drivers

identify the reason for the interrupt (device connect, write acknowledge, data available) and set or clear device state bits as appropriate. It can also awaken processes that are sleeping, waiting for an event corresponding to the interrupt.