Kernel Interface

A device driver at the user application level supports the same user interface as the file system, namely; open, close, read, and write routines. A device driver implements this concept through the use of kernel services.

In its simplest form, a device driver moves data between hardware devices and user applications where the user applications supply and consume information.

It may also be involved in the translation of information. Presenting information to the application that is translated from the tty services is an example of this.

In addition to supplying a user with information, a computer employs numerous types of devices for storing and collecting data. Device drivers provide a transparent method for managing information storage and retrieval.

For example, a device driver moves keystrokes to a program and moves characters to the screen for display. In this simple view a device driver is trivial. However, because there is typically more time spent waiting for devices to input and output information on Unix machines, the design is to allow multiple users to input/output data. This complicates the system dramatically.

The kernel services provide services for moving data, serializing the use of data, data integrity and notification of data delivery. With these mechanisms a device driver can satisfy the need for information among many users while optimizing the resources of the machine.

3.2.1 The Device Switch Table

The device switch table binds the device driver to the system and extends the kernel. The kernel however needs to advertise that the service is available.

Advertisement is accomplished through the file system and the mknod command. The special file provides a name which is translated to a device number. The device number is then used to index the switch table.

The order of operations in your device driver configuration routine should make sure that the mknod is issued as the last command, allowing the driver to be completely set up before any user is able to access the device driver. See

"Adapter Configuration Method (cfgrica.c)" on page 8-28 for sample configuration code.

The AIX device switch table provides services for collecting and storing device driver location information. In addition, kernel services are provided for querying the entries.

devswqry query to see if a device and associated routines and configuration information are available.

devswadd adds information for a device driver to the device switch table.

devswdel deletes information for a device driver from the device switch table.

The kernel services listed above are the only method for accessing the device switch table. This is different than other Unix systems that provide direct access to the switch table. Direct access to the switch table on AIX would be potentially a problem because it is a global data structure. Any number of users could be adding a device driver and so the problems of serialization exist.

There are other global kernel data structures that are also implemented using a service to alter and read information instead of providing a global variable. That is why some kernel services exist - to serialize the access and changing of global data structures.

The following entry points exist in the device switch table. These entry paints (routines) will be discussed in subsequent sections:

• open routine entry point

• close routine entry point

• read routine entry point

• write routine entry paint

• ioctl routine entry point

• strategy routine entry point

• select routine entry point

• config routine entry point

• print routine entry point

• dump routine entry point

• mpx routine entry point

• revoke routine entry point.

Note that not all routines are required. If a routine is not required, the entry in the device switch table can call one of two special kernel routines nodevor nulldev. An entry point can be assigned a null value. This will result in a call to a dummy kernel routine called nulldev which will always return a successful return code. An entry point can also be assigned a value of nodev. This will result in a return code value of ENODEV.

3.2.2 Entry Points Common to Character and Block Device Drivers

Please refer to "Overview of a Character Device Driver" on page 4-1 for

detailed information on character device driver entry points and to "Overview of a Block Device Driver" on page 5-1 for detailed information on block device driver entry points.

The names of entry points (like ddconfig, ddopen, ddread, etc.) do not mean anything in terms of symbols exported by the kernel. They are place holder names purely for description. Your driver is ONLY bound to the kernel through the switch table. The device switch table expects an entry in each field whether or not your driver supports such a routine. See nodev or nulldev if you do not have a routine. Your driver may export symbols but please see" Pinning Device Driver Code" on page 10-1 for a description of possible problems that can be caused by referencing code that is not pinned.

The following entry points are common for both character and block device drivers:

• ddconfig

The ddconfig routine is an AIX innovation and is not part of standard Unix.

This routine supports run time and IPL time configuration of the device driver. Typically, it is the first routine in your driver but may be placed elsewhere. ddconfig is responsible for reading the configuration information requested by the user/administrator, setting the driver up according to this information and binding the routines in the driver to the switch table so that the user level configuration routine (configuration method) can complete.

This makes the user interface available (open, close, read, write) for use.

• ddopen

The ddopen routine binds a user to the device driver. Some drivers wait until open to finish configuring additional device parameters. Also, some drivers support multiple users per device (for example, the token-ring and Ethernet device drivers do this). Others handle multiplexing through user-written routines such as the printer backend services (piobe). The open routine determines whether one or more users may be allowed to access the device concurrently.

• ddclose

The ddclose routine is responsible for deallocating resources associated with a particular user.

• ddioctl

The ddioctl routine provides control commands and parameters to the device.

• dddump

The dddump routine allows the device driver to use the device as the target of a system dump. Usually hard disks or tape devices will have this

capability.

3.2.3 Entry Points for Character and Raw Access to Block Device Driver

• ddread

Allows data to be read from a device. This is sequential data specified as one or more bytes.

• ddwrite

Allows sequential data to be written to a device.

3.2.4 Entry Points Unique to Character Device Drivers

• ddselect

Allows a user to poll a hardware device to determine whether specific events should have occurred.

• ddmpx

Allows for multiple users to share a resource on a hardware adapter. For example, this could be a port on a communications adapter.

3.2.5 Entry Points Unique to Block Device Drivers

• ddstrategy

Allows block-oriented reads or writes to be performed on a block-oriented device (like a hard disk).

3.2.6 Entry Points for Trusted Computing Path Device Drivers

• ddrevoke

Allows a character device driver to disable a device for all users. This results in a particular user having exclusive access to a device. This entry point is only required for devices that are supported in the trusted

computing path.

3.2.7 Miscellaneous Entry Points NOT Found in the Device Switch Table

The following routines do not have entries in the device switch table. They are registered using kernel services.

The start 1/0 routine is typically known only to other routines within the device driver, such as the strategy and interrupt-handling routines.

Interrupt handling routines are also registered using kernel services. Note that some character device drivers, particularly pseudo-device drivers, may not have a bottom half if they have no need to execute in the interrupt environment.

The entry pOint for the component dump routine is registered with the kernel at initialization time. This is registered by using the dmp_add kernel service. The purpose of the component dump routine is to allow your device driver to save tables and information if something causes a system dump to happen. See

"Including Device Driver Information in a System Dump" on page 9-2 for more information.

HINT ---~

Writing and registering a component dump routine for your device driver can be very useful for tracing the cause of abnormal system dumps related to your driver.