The buf structure

Figure 5-2. The mbuf structure

A buf header contains all the information required to perform block I/O. The buf structure is shown in Figure 5-2 It is the primary interface to the bottom half of block device drivers. In AIX version 3, the traditional strategy interface is extended as follows:

1. The device driver strategy routine is called with a list of buf structures, chained using the av_forw pointer. The last entry in this list has a NULL av_forw pointer.

2. When the operation is completed, and the driver calls iodone, the b_iodone function defined by the caller is scheduled to run as a software interrupt handler.

The buf struct and its associated data page must be pinned before calling the strategy routine. This is by definition in the

<

>

The buf stucture contains the operation to be performed and status information to be returned to the caller and is more like a message exchanged between requestor and service provider.

The caller is notified of I/O completion (or of an error associated with the request) by the device driver's call to iodone kernel sevices. A residual count of the number of bytes requested but not tranfered by the operation is placed in the b_resid field of the buf structure by the device driver before the I/O is marked as complete for the buffer header. If all the requested bytes are transfered then this count will be set to O.

5.1.1.4 Reordering Block 1/0 Requests

Multiple I/O request can also be presented to the strategy routine, where the additional buffer headers may be chained to the first by using the

av_Iorw

pointers. While the device strategy routine is free to rearrange the buffers on it's device queue with respect to the processing of single request, the ordering of the buffer headers provided in a chain to the strategy routine cannot be modified. The strategy routine also determine if the block number requested is valid for the device. In the case of a read only operation, a block number at the end-of-media is not considered as an error, but no data is transfered. For a write operation, if the block number is at the end-of-media, it is considered as an error and the B_ERROR flag in the buf structure should be set, and the b_error field should also contain the ENXIO value.

5.1.1.5 Categorizing Requests To The Start 1/0 Routine

To maintain the state of the device and it's I/O requests, the device driver will typically allocate a private data structure in the system memory associated with the device. The data structure contains device status along with the device error information and the device queue pOinters. Some device drivers will maintain more than one queue of buffer headers, for example, one queue for the requests that are waiting for I/O start and another queue for the request that are currently in process.

For SCSI, the queueing process scans the pending queue for the requested device so that the number of SCSI operations is minimized. The requests will be grouped by one of the following rules:

1. Contiguous write operations

2. Operations larger than maximum transfer size 3. Operations requiring special processing

The coalesced (grouped) requests will be removed from the pending queue and placed in the inyrogress queue so that a single command may be built to satisfy the requests. These requests are then queued and the start I/O routine is called.

5.1.1.6 Starting Processing With The Start 1/0 Routine

The start 1/0 routine checks to make sure that the device is not busy, and then scans the request queues in an attempt to find an operation to start. First the command stack is checked to see if a command needs to be restarted, and then the inyrogress queue is checked to start any operations that have already been coalesced. Finally, the pending queue is checked. If it is not empty, the coalesce routine is called to group the operations into the inyrogress queue.

When a request has been found and built, the adapter device driver is called via the strategy routine in order to begin processing of the operation. While the

queues are being scanned and an operation is in progress, the device busy flag is set. It is then reset if no request is found.

Once the I/O handling routine has completed an I/O transfer it calls the iodone routine that determines if the indicated operation has completed successfully or if it has failed. If the operation was successful and complete, then the next request is processed via the start I/O routine. If the operation has failed. your general failure processing routine is called in an attempt to clear the error (retry. etc).

5.1.1.7 dddump Entry Point

The dddump entry point is supplied by a block device driver if it is to be capable of supporting system dumps. It is invoked by devdump. (See "System Dump" on page 9-1 for information on supporting the system dump.) The dddump routine provides a return code to devdump. See "dddump Device Driver Entry Point" on page 4-52 for information on the dddump entry point.

5.1.1.8 ddloctl Entry Point

In addition to supplying statistical information about the device, the ioctl can be used for a block device to control operations of the device. However, when the strategy routine is invoked. it should not be depe.ndent upon any ioctl

operations.

5.1.2 Character Access to Block Device Drivers

As previously mentioned. character access to block device drivers is known as raw 110. While a character device driver can only be accessed by a character special file. most block device drivers provide both a block and a character special file. This dual interface supports a user being able to access the device in either block or character mode. Note that the block device driver must have a read and a write entry point as well as a strategy entry point if it is to support both character and block mode access. (If only block mode is supported, only a stategy entry point need be supported.)

Examples of the duality provided by a block device drivers are the diskette or the hard-disk device drivers. The diskette is accessed by /dev/fdO for block mode and by /dev/rfdO for raw mode. The hard disk is accessed by /dev/hdiskO for block mode and /dev/rhdiskO for raw mode.

5.1.2.1 Raw 110 Processing

The raw I/O processing is a mechanism by which a block device driver has the ability to transfer data without using the I/O buffer cache. Instead the raw I/O request is converted into a block and then sent to the the device driver strategy entry point to be processed while the read and the write routines are typically waiting for the I/O completion.

When your device driver is configured it will contain entries for both read/write (raw access) and strategy (block access). In addition, the configuration entry point must set up the /dev entries for both. (See "ddconfig Entry Point" on page 5-2.)

If there is no buffer cache and the user is making the request directly then a different buffering facility is involved. Namely. the user is providing a buffer passed in through the uio services. Therefore the read and write entry points are talking to a user process and translating the requests into strategy requests

but still using buf.h. Because the buf.h structure is a header that contains a pointer to the data area it can be mapped to point to a user data area.

In fact, the user buffer could come out of user data, text segments, shared memory segments or the system segment. The different areas are defined in the uio structure through the iovecs.

The read/write routines of the raw device driver use the uphysio services to map the uio areas into buf structs used by the strategy routines. This is discussed in Understanding Raw I/O Support in Kernel Extensions and Concepts.

5.1.3 Block 1/0 Device Device Summary

A block I/O device contains a device name for it's block device and it's optional character device. Block devices support strategy and read and write routines.

mkfs and fsck use the read and write interfaces to perform maintenance on the device while the AIX file system, and virtual memory management work together to provide the traditional Unix Kernel cache.

The kernel cache speeds up access to data by allowing mulitple processes to use the same data and keeping data that is referenced often in the cache.

However the cache is based on buffer sizes compatible with Unix file system block sizes and is not efficient for applications that may want to use larger block sizes. To help performance a block device driver should also provide raw access or character access to block devices.

More information - - - . . . , For more information on block device drivers and block I/O kernel services, please refer to the Kernel Extensions and Device Support Programming Concepts manual.

Chapter 6. Device Drivers Configuration

6.1 Introduction

Unlike classic Unix device drivers, in AIX Version 3, device drivers are

dynamically loaded either at or after system boot time. They are not statically linked into the kernel on disk. This eliminates a great deal of administrative overhead associated with maintaining the AIX kernel, and makes the system simpler to administer and extend. However, it does add to the complexity of the device driver and associated routines.

At system boot time AIX automatically examines the configuration of the system and loads the appropriate device drivers. It also resolves conflicts between various adapters (for I/O port addresses, IRQ levels, etc.). This is called the AIX device configuration subsystem and it performs a variety of functions:

• It scans the Micro Channel bus to determine the two-byte unique POS code for the adapter in each slot.

• It examines the OOM database to determine the characteristics of these adapters.

• It assigns resources (IRQ levels, buffer addresses, DMA levels, I/O port addresses) to each adapter to avoid conflicts.

• It calls the configuration method for each device to be configured; this loads and initializes the device driver. Every device must have a configuration method. This will be described later in this chapter.

In the AIX device configuration subsystem, the term device has a wider range of meaning than it does in traditional Unix systems.

In both AIX and Unix systems, the term "device" refers to hardware components such as disk drives, tape drives, printers, and keyboards. Pseudo-devices, such as the console, error, and the null special file, are also included. For AIX, all of these devices are referred to as the kernel devices, that is, the devices with device drivers and known to the system by major and minor numbers.

However, in the AIX operating system, hardware components such as buses, adapters, and even enclosures (including racks, drawers, and expansion boxes) are also considered devices (Figure 6-3 on page 6-9 shows an example of connections and dependencies between these components).

Note that the system cannot use any device unless it is configured.

6.1.1 General Structure of the Device Configuration Subsystem

The Device Configuration Subsystem can be viewed from three different administration levels: the High Level Administration Perspective, the Device Method Level, and the Low Level Perspective (Figure 6-1 on page 6-2 illustrates the general structure of the configuration subsystem).