In order to build a working data transfer for sbull, let’s look at how the kernel describes a request within a struct request. The structure is defined in <linux/blkdev.h>. By accessing the fields in CURRENT, the driver can retrieve all the information needed to transfer data between the buffer cache and the physical block device.

CURRENT is a macro that is used to access the current request (the one to be serviced first). As you might guess, CURRENT is a short form of blk_dev[MAJOR_NR].current_request.

The following fields of the current request carry useful information for the request function:

There are other fields in the structure, but they are primarily meant for internal use in the kernel; the driver is not expected to use them.

The implementation for the working request function in the sbull device is shown below. In the following code, sbull_devices is like scull_devices, introduced in Section 3.5.1 in Chapter 3.

void sbull_request(void)
{
    Sbull_Dev *device;
    u8 *ptr;
    int size;

    while(1) {
        INIT_REQUEST;

        /* Check if the minor number is in range */
        if (DEVICE_NR(CURRENT_DEV) > sbull_devs) {
            static int count = 0;
            if (count++ < 5)  /* print the message at most 5 times */
                printk(KERN_WARNING
                           "sbull: request for unknown device
");
            end_request(0);
            continue;
        }

        /* pointer to device structure, from the global array */
        device = sbull_devices + DEVICE_NR(CURRENT_DEV);
        ptr = device->data + CURRENT->sector * sbull_hardsect;
        size = CURRENT->current_nr_sectors * sbull_hardsect;
        if (ptr + size > device->data + sbull_blksize*sbull_size) {
            static int count = 0;
            if (count++ < 5)
                printk(KERN_WARNING
                           "sbull: request past end of device
");
            end_request(0);
            continue;
        }

        switch(CURRENT->cmd) {
          case READ:
            /* from sbull to buffer */
            memcpy(CURRENT->buffer, ptr, size);
            break;
          case WRITE:
            /* from buffer to sbull */
            memcpy(ptr, CURRENT->buffer, size);
            break;
          default:
            /* can't happen */
            end_request(0);
            continue;
        }


        end_request(1); /* success */
    }
}

Since sbull is just a RAM disk, its ``data transfer'' reduces to a memcpy call. The only ``strange'' feature of the function is the conditional statement that limits it to reporting five errors. This is intended to avoid clobbering the system logs with too many messages, since end_request(0) already prints an ``I/O error'' message when the request fails. The static counter is a standard way to limit message reporting and is used several times in the kernel.

Each iteration of the loop in the request function above transfers a number of sectors--usually the number of sectors that equals a ``block'' of data, according to the use of such data. For instance, swapping is performed PAGE_SIZE bytes at a time, while an extended-2 filesystem transfers 1KB blocks.

Although a block is the most convenient data size for I/O, you can get a significant performance boost by clustering the reading or writing of adjacent blocks. In this context, ``adjacent'' refers to the location of blocks on the disk, while ``consecutive'' refers to consecutive memory areas.

There are two advantages to clustering adjacent blocks. First, clustering speeds up the transfer (for example, the floppy driver assembles adjacent blocks and transfers a whole track at a time). It can also save memory in the kernel by avoiding allocation of redundant request structures.

You can, if you want, completely ignore clustering. The skeletal request function shown above works flawlessly, independent of clustering. If you want to exploit clustering, on the other hand, you need to deal in greater detail with the internals of struct_request.

Unfortunately, all kernels I know of (up to at least 2.1.51) don’t perform clustering for custom drivers, just for internal drivers like SCSI and IDE. If you aren’t interested in the internals of the kernel, you can skip the rest of this section. On the other hand, clustering might be available to modules in the future, and it is an interesting way to increase data-transfer performance by reducing inter-request delays for adjacent sectors.

Before I describe how a driver can exploit clustered requests, let’s look at what happens when a request is queued.

When the kernel requests the transfer of a data block, it scans the linked list of active requests for the target device. If the new block is adjacent on the disk to a block that has already been requested, the new block is clustered to the first block; the existing request is enlarged without creating a new one.

Unfortunately, the fact that the contents of two data buffers are adjacent on disk doesn’t necessarily mean that they are consecutive in memory. This observation, plus the need to efficiently manage the buffer cache, led to the creation of a buffer_head structure. One buffer_head is associated with each data buffer.

A ``clustered'' request, then, is a single request_struct that refers to a linked list of buffer_head structures. The end_request function takes care of this problem, and that’s why the request function shown earlier works independent of clustering. In other words, end_request either cleans up the current request and prepares to service the next one, or prepares to deal with the next buffer in the same request. Clustering is therefore transparent to the device driver that doesn’t care about it; the sbull function above is such an example.

A driver may want to benefit from clustering by dealing with the whole linked list of buffer heads at each pass through the loop in its request_fn function. To do this, the driver should refer to both CURRENT->current_nr_sectors (the field I already used above in sbull_request) and CURRENT->nr_sectors, which contains the number of adjacent sectors that are clustered in the ``current'' list of buffer_heads.

The current buffer head is CURRENT->bh, while the data block is CURRENT->bh->b_data. The latter pointer is cached in CURRENT->buffer for drivers like sbull that ignore clustering.

Request clustering is implemented in drivers/block/ll_rw_block.c, in the function make_request; however, as suggested above, clustering is performed only for a few drivers (floppy, IDE, and SCSI), according to their major number. I’ve been able to see how clustering works by loading sbull with major=34 because 34 is IDE3_MAJOR, and I don’t have the third IDE controller on my system.^[30]

The following list summarizes what needs to be done when scanning a clustered request. bh is the buffer head being processed--the first in the list. For every buffer head in the list, the driver should carry out the following sequence of operations:

When you are done with the clustered request, CURRENT->bh must be updated to point to the first buffer that was ``processed but not unlocked.'' If all the buffers in the list were processed and unlocked, CURRENT->bh can be set to NULL.

At this point, the driver can call end_request. If CURRENT->bh is valid, the function unlocks it before moving to the next buffer--this is what happens for non-clustered operation, where end_request takes care of everything. If the pointer is NULL, the function just moves to the next request.

A full-featured implementation of clustering appears in drivers/block/floppy.c, while a summary of the operations required appears in end_request, in blk.h. Neither floppy.c nor blk.h are easy to understand, but the latter is a better place to start.