Linux Device Drivers (3rd Edition) [Electronic resources] نسخه متنی

Chapter 16. Block Drivers

So far, our discussion has been limited to char drivers. There are
other types of drivers in Linux systems, however, and the time has
come for us to widen our focus somewhat. Accordingly, this chapter
discusses block drivers.

A block driver provides access to devices that transfer randomly
accessible data in fixed-size blocksdisk drives, primarily.
The Linux kernel sees block devices as being fundamentally different
from char devices; as a result, block drivers have a distinct
interface and their own particular challenges.

Efficient
block drivers are critical for
performanceand not just for explicit reads and writes in user
applications. Modern systems with virtual memory work by shifting
(hopefully) unneeded data to secondary storage, which is usually a
disk drive. Block drivers are the conduit between core memory and
secondary storage; therefore, they can be seen as making up part of
the virtual memory subsystem. While it is possible to write a block
driver without knowing about struct
page and other important memory concepts, anybody
needing to write a high-performance driver has to draw upon the
material covered in Chapter 15.

Much of the design of the block layer is centered on performance.
Many char devices can run below their maximum speed, and the
performance of the system as a whole is not affected. The system
cannot run well, however, if its block I/O subsystem is not
well-tuned. The Linux block driver interface allows you to get the
most out of a block device but imposes, necessarily, a degree of
complexity that you must deal with. Happily, the 2.6 block interface
is much improved over what was found in older kernels.

The discussion in this chapter is, as one would expect, centered on
an example driver that implements a block-oriented, memory-based
device. It is, essentially, a ramdisk. The kernel already contains a
far superior ramdisk implementation, but our driver (called
sbull) lets us demonstrate the creation of a
block driver while minimizing unrelated complexity.

Before getting into the details, let's define a
couple of terms precisely. A block is a
fixed-size chunk of data, the size being determined by the kernel.
Blocks are often 4096 bytes, but that value can vary depending on the
architecture and the exact filesystem being used. A
sector, in contrast, is a small block whose
size is usually determined by the underlying hardware. The kernel
expects to be dealing with devices that implement 512-byte sectors.
If your device uses a different size, the kernel adapts and avoids
generating I/O requests that the hardware cannot handle. It is worth
keeping in mind, however, that any time the kernel presents you with
a sector number, it is working in a world of 512-byte sectors. If you
are using a different hardware sector size, you have to scale the
kernel's sector numbers accordingly. We see how that
is done in the sbull driver.