Chapter 6: Device Drivers
❑ The device number for the block device is stored inbd_dev.^7
❑ A link back to the inode that represents the block device in thebdevpseudo-filesystem is given
bybd_inode(basically, this could also be obtained usingbdget, so the information is redundant,
and the field will be removed in a future kernel version).
❑ bd_inodesheads a list of all inodes that represent device special files for the block device.These inodes represent regular files and must not be confused with thebdevinode,
which represents the block device itself!❑ bd_openerscounts how often the block device has been opened withdo_open.
❑ bd_partpoints to a specialized data structure (struct hd_struct) that represents the partition
contained on the block device. I will come back to this representation in a moment.
❑ bd_part_countdoesnotcount the number of partitions as could be assumed. Instead, it is a
usage count that states from how many places in the kernel partitions within the device have
been referenced.
This is necessary when partitions are rescanned withrescan_partitions:Ifbd_part_countis
greater than zero, rescanning is refused because the old partitions are still in use.
❑ bd_invalidatedis set to 1 if the partition information in the kernel is invalid because it has
changed on disk. Next time the device is opened, the partition tables will be rescanned.
❑ bd_diskprovides another abstraction layer that also allows for partitioning hard disks. This
mechanism is examined in the following section.
❑ bd_listis a list element that allows for keeping track of allblock_deviceinstances available in
the system. The list is headed by the global variableall_bdevs. This allows for iterating over all
block devices without querying the block device database.
❑ bd_privatecan be used to store holder-specific data with eachblock_deviceinstance.As the term holder-specific implies, only the current holder of theblock_device
instance may usebd_private. To become a holder,bd_claimneeds to be
successfully called on the block device.bd_claimis successful ifbd_holderis aNULL
pointer, that is, if no holder is yet registered. In this case,bd_holderpoints to the
current holder, which can be an arbitrary address in kernel space. Callingbd_claim
signalizes to other parts of the kernel that they essentially do not have any business
with the block device anymore.There are no fixed rules on which part of the kernel can hold a block device. The Ext3 filesystem,
for instance, claims the block device which represents an external journal of a mounted filesys-
tem, and the superblock is registered as a holder. If a partition is used as a swap space, then the
swapping code holds the partition after it is activated with theswaponsystem call.(^7) The comment on data typekdev_tis included for historical reasons. When development work started on 2.6 the kernel used
two different data types (dev_tandkdev_t) to represent device numbers inside and outside the kernel.