Chapter 6: Device Drivers
❑ Accesses to block devices are massively cached; that is, read data are kept in memory and are
accessed from there if they are needed again. Write operations are also delayed by using caches.
This makes no sense on character devices (such as keyboards); each read request must be satis-
fied by genuine interaction with the device.We use two terms repeatedly below — block and sector. Ablockis a byte sequence of a specific size
used to hold data transferred between the kernel and a device; the size of the block can be modified by
software means. Asectoris a fixed hardware unit and specifies the smallest amount of data that can be
transferred by a device. A block is nothing more than a sequence of successive sectors; consequently,
the block size must always be an integer multiple of the sector size. As a sector is a hardware-specific
constant, it is also used to specify the position of a data block on a device. The kernel regards each block
device as a linear list of integer-numbered sectors or blocks.Today, almost all common block devices have a sector size of 512 bytes, which equates to a block size
of 512, 1,024, 2,048 or 4,096. It should, however, be noted that the maximum block size is limited by the
memory page size of the particular architecture. IA-32 systems support a maximum block size of 4,096
bytes because the memory page size is 4,096 bytes. On the other hand, IA-64 and Alpha systems are able
to handle blocks with 8,192 bytes.The relative freedom of choice with regard to block size has advantages for many block device applica-
tions as you will see when examining, for example, how filesystems are implemented. Filesystems may
divide the hard disk into blocks of different sizes in order to optimize performance when many small
files or few large files are involved. Implementation is made much easier because the filesystem is able to
match the transfer block size to its own block size.The block device layer is not only responsible for addressing the block devices but also for carrying
out other tasks to enhance the performance of all block devices in the system. Such tasks include the
implementation ofreadaheadalgorithms that read data from a block device speculatively in advance
when the kernel assumes that the data will be required shortly by an application program.The block device layer must provide buffers and caches to hold the readahead data if they are not
required immediately. Such buffers and caches are not reserved solely for readahead data but are also
used to temporarily store frequently needed block device data.The list of tricks and optimizations performed by the kernel when addressing block devices is long and
beyond the scope of this chapter. What is more important is to sketch the various components of the
block device layer and demonstrate how they interact.6.5.1 Representation of Block Devices
Block devices have a set of characteristic properties managed by the kernel. The kernel uses what is
known asrequest queue managementto support communication with devices of this kind as effectively as
possible. This facility enables requests to read and write data blocks to be buffered and rearranged. The
results of requests are likewise kept in caches so that the data can be read and reread in a very efficient
way. This is useful when a process repeatedly accesses the same part of a file or when different processes
access the same data in parallel.A comprehensive network of data structures as described below is needed to perform these tasks.
Figure 6-9 shows an overview of the various elements of the block layer.