Linux Device Drivers

Interrupt-Driven Block Drivers

When a driver controls a real hardware device, operation is usually interrupt-driven. Using interrupts helps system performance by releasing the processor during I/O operations. In order for interrupt-driven I/O to work, the device being controlled must be able to transfer data asynchronously and to generate interrupts.

When the driver is interrupt-driven, the request function spawns a data transfer and returns immediately without calling end_request. However, the kernel doesn’t consider a request fulfilled unless end_request has been called. Therefore, the top-half or the bottom-half interrupt handler calls end_request when the device signals that the data transfer is complete.

Neither sbull nor spull can transfer data without using the system microprocessor; however, spull is equipped with the capability of faking interrupt-driven operation by specifying the irq=1 option at load time. When irq is not zero, the driver uses a kernel timer to delay fulfillment of the current request. The length of the delay is the value of irq: the greater the value, the longer the delay.

The request function for an interrupt-driven device instructs the hardware to perform the transfer and then return. The spull function performs the usual error checks and then calls memcpy to transfer the data (this is the task that a real driver performs asynchronously). It then delays acknowledgment until interrupt time:

void spull_irqdriven_request(void) { Spull_Dev *device; ...