块设备与字符设备的区别
1、 从字面上理解，块设备和字符设备最大的区别在于读写数据的基本单元不同。块设备读写数据的基本单元为块，例如磁盘通常为一个 sector ，而字符设备的基本单元为字节。所以 Linux 中块设备驱动往往为磁盘设备的驱动，但是由于磁盘设备的 IO 性能与 CPU 相比很差，因此，块设备的数据流往往会引入文件系统的 Cache 机制。
2、 从实现角度来看， Linux 为块设备和字符设备提供了两套机制。字符设备实现的比较简单，内核例程和用户态 API 一一对应，用户层的 Read 函数直接对应了内核中的 Read 例程，这种映射关系由字符设备的 file_operations 维护。块设备接口相对于字符设备复杂， read 、 write API 没有直接到块设备层，而是直接到文件系统层，然后再由文件系统层发起读写请求。
块设备读写流程
在学习块设备原理的时候，我最关系块设备的数据流程，从应用程序调用 Read 或者 Write 开始，数据在内核中到底是如何流通、处理的呢？然后又如何抵达具体的物理设备的呢？下面对一个带 Cache 功能的块设备数据流程进行分析。
1、 用户态程序通过 open() 打开指定的块设备，通过 systemcall 机制陷入内核，执行 blkdev_open() 函数，该函数注册到文件系统方法（ file_operations ）中的 open 上。在 blkdev_open 函数中调用 bd_acquire() 函数， bd_acquire 函数完成文件系统 inode 到块设备 bdev 的转换，具体的转换方法通过 hash 查找实现。得到具体块设备的 bdev 之后，调用 do_open() 函数完成设备打开的操作。在 do_open 函数中会调用到块设备驱动注册的 open 方法，具体调用如下： gendisk->fops->open(bdev->bd_inode, file) 。
2、 用户程序通过 read 、 write 函数对设备进行读写，文件系统会调用相应的方法，通常会调用如下两个函数： generic_file_read 和 blkdev_file_write 。在读写过程中采用了多种策略，首先分析读过程。
3、 用户态调用了 read 函数，内核执行 generic_file_read ，如果不是 direct io 方式，那么直接调用 do_generic_file_read->do_generic_mapping_read() 函数，在 do_generic_mapping_read （函数位于 filemap.c ）函数中，首先查找数据是否命中 Cache ，如果命中，那么直接将数据返回给用户态；否则通过 address_space->a_ops->readpage 函数发起一个真实的读请求。在 readpage 函数中，构造一个 buffer_head ，设置 bh 回调函数 end_buffer_async_read ，然后调用 submit_bh 发起请求。在 submit_bh 函数中，根据 buffer_head 构造 bio ，设置 bio 的回调函数 end_bio_bh_io_sync ，最后通过 submit_bio 将 bio 请求发送给指定的快设备。
4、 如果用户态调用了一个 write 函数，内核执行 blkdev_file_write 函数，如果不是 direct io 操作方式，那么执行 buffered write 操作过程，直接调用 generic_file_buffered_write 函数。 Buffered write 操作方法会将数据直接写入 Cache ，并进行 Cache 的替换操作，在替换操作过程中需要对实际的快设备进行操作， address_space->a_ops 提供了块设备操作的方法。当数据被写入到 Cache 之后， write 函数就可以返回了，后继异步写入的任务绝大部分交给了 pdflush daemon （有一部分在替换的时候做了）
5、 数据流操作到这一步，我们已经很清楚用户的数据是如何到内核了。与用户最接近的方法是 file_operations ，每种设备类型都定义了这一方法（由于 Linux 将所有设备都看成是文件，所以为每类设备都定义了文件操作方法，例如，字符设备的操作方法为 def_chr_fops ，块设备为 def_blk_fops ，网络设备为 bad_sock_fops ）。每种设备类型底层操作方法是不一样的，但是通过 file_operations 方法将设备类型的差异化屏蔽了，这就是 Linux 能够将所有设备都理解为文件的缘由。到这里，又提出一个问题：既然这样，那设备的差异化又该如何体现呢？在文件系统层定义了文件系统访问设备的方法，该方法就是 address_space_operations ，文件系统通过该方法可以访问具体的设备。对于字符设备而言，没有实现 address_space_operations 方法，也没有必要，因为字符设备的接口与文件系统的接口是一样的，在字符设备 open 操作的过程中，将 inode 所指向的 file_operations 替换成 cdev 所指向的 file_operations 就可以了。这样用户层读写字符设备可以直接调用 cdev 中 file_operations 方法了。
6、 截至到步骤（ 4 ），读操作在没有命中 Cache 的情况下通过 address_space_operations 方法中的 readpage 函数发起块设备读请求；写操作在替换 Cache 或者 Pdflush 唤醒时发起块设备请求。发起块设备请求的过程都一样，首先根据需求构建 bio 结构， bio 结构中包含了读写地址、长度、目的设备、回调函数等信息。构造完 bio 之后，通过简单的 submit_bio 函数将请求转发给具体的块设备。从这里可以看出，块设备接口很简单，接口方法为 submit_bio （更底层函数为 generic_make_request ），数据结构为 struct bio 。
7、 submit_bio 函数通过 generic_make_request 转发 bio ， generic_make_request 是一个循环，其通过每个块设备下注册的 q->make_request_fn 函数与块设备进行交互。如果访问的块设备是一个有 queue 的设备，那么会将系统的 __make_request 函数注册到 q->make_request_fn 中；否则块设备会注册一个私有的方法。在私有的方法中，由于不存在 queue 队列，所以不会处理具体的请求，而是通过修改 bio 中的方法实现 bio 的转发，在私有 make_request 方法中，往往会返回 1 ，告诉 generic_make_request 继续转发比 bio 。 Generic_make_request 的执行上下文可能有两种，一种是用户上下文，另一种为 pdflush 所在的内核线程上下文。
8、 通过 generic_make_request 的不断转发，最后请求一定会到一个存在 queue 队列的块设备上，假设最终的那个块设备是某个 scsi disk （ /dev/sda ）。 generic_make_request 将请求转发给 sda 时，调用 __make_request ，该函数是 Linux 提供的块设备请求处理函数。在该函数中实现了极其重要的操作，通常所说的 IO Schedule 就在该函数中实现。在该函数中试图将转发过来的 bio merge 到一个已经存在的 request 中，如果可以合并，那么将新的 bio 请求挂载到一个已经存在 request 中。如果不能合并，那么分配一个新的 request ，然后将 bio 添加到其中。这一切搞定之后，说明通过 generic_make_request 转发的 bio 已经抵达了内核的一个站点—— request ，找到了一个临时归宿。此时，还没有真正启动物理设备的操作。在 __make_request 退出之前，会判断一个 bio 中的 sync 标记，如果该标记有效，说明请求的 bio 是一个是实时性很强的操作，不能在内核中停留，因此调用了 __generic_unplug_device 函数，该函数将触发下一阶段的操作；如果该标记无效的话，那么该请求就需要在 queue 队列中停留一段时间，等到 queue 队列触发闹钟响了之后，再触发下一阶段的操作。 __make_request 函数返回 0 ，告诉 generic_make_request 无需再转发 bio 了， bio 转发结束。
9、 到目前为止，文件系统（ pdflush 或者 address_space_operations ）发下来的 bio 已经 merge 到 request queue 中，如果为 sync bio ，那么直接调用 __generic_unplug_device ，否则需要在 unplug timer 的软中断上下文中执行 q->unplug_fn 。后继 request 的处理方法应该和具体的物理设备相关，但是在标准的块设备上如何体现不同物理设备的差异性呢？这种差异性就体现在 queue 队列的方法上，不同的物理设备， queue 队列的方法是不一样的。举例中的 sda 是一个 scsi 设备，在 scsi middle level 将 scsi_request_fn 函数注册到了 queue 队列的 request_fn 方法上。在 q->unplug_fn （具体方法为： generic_unplug_device ）函数中会调用 request 队列的具体处理函数 q->request_fn 。 Ok ，到这一步实际上已经将块设备层与 scsi 总线驱动层联系在了一起，他们的接口方法为 request_fn （具体函数为 scsi_request_fn ）。
10、 明白了第（ 9 ）点之后，接下来的过程实际上和具体的 scsi 总线操作相关了。在 scsi_request_fn 函数中会扫描 request 队列，通过 elv_next_request 函数从队列中获取一个 request 。在 elv_next_request 函数中通过 scsi 总线层注册的 q->prep_rq_fn （ scsi 层注册为 scsi_prep_fn ）函数将具体的 request 转换成 scsi 驱动所能认识的 scsi command 。获取一个 request 之后， scsi_request_fn 函数直接调用 scsi_dispatch_cmd 函数将 scsi command 发送给一个具体的 scsi host 。到这一步，有一个问题： scsi command 具体转发给那个 scsi host 呢？秘密就在于 q->queuedata 中，在为 sda 设备分配 queue 队列时，已经指定了 sda 块设备与底层的 scsi 设备（ scsi device ）之间的关系，他们的关系是通过 request queue 维护的。
11、 在 scsi_dispatch_cmd 函数中，通过 scsi host 的接口方法 queuecommand 将 scsi command 发送给 scsi host 。通常 scsi host 的 queuecommand 方法会将接收到的 scsi command 挂到自己维护的队列中，然后再启动 DMA 过程将 scsi command 中的数据发送给具体的磁盘。 DMA 完毕之后， DMA 控制器中断 CPU ，告诉 CPU DMA 过程结束，并且在中断上下文中设置 DMA 结束的中断下半部。 DMA 中断服务程序返回之后触发软中断，执行 SCSI 中断下半部。
12、 在 SCSi 中断下半部中，调用 scsi command 结束的回调函数，这个函数往往为 scsi_done ，在 scsi_done 函数调用 blk_complete_request 函数结束请求 request ，每个请求维护了一个 bio 链，所以在结束请求过程中回调每个请求中的 bio 回调函数，结束具体的 bio 。 Bio 又有文件系统的 buffer head 生成，所以在结束 bio 时，回调 buffer_head 的回调处理函数 bio->bi_end_io （注册为 end_bio_bh_io_sync ）。自此，由中断引发的一系列回调过程结束，总结一下回调过程如下： scsi_done->end_request->end_bio->end_bufferhead 。
13、 回调结束之后，文件系统引发的读写操作过程结束。
初始化一个块设备
每个块设备都拥有一个操作接口： struct block_device_operations ，该接口定义了 open 、 close 、 ioctl 等函数接口，但没有，也没有必要定义 read 、 write 函数接口。
初始化一个块设备的过程如下：
int setup_device(block_dev_t *dev, int minor)
{
int hardsect_size = HARDSECT_SIZE;
int chunk_size;
sector_t dev_size;
/* 分配一个请求队列 */
dev->queue = blk_alloc_queue(GFP_KERNEL);
if (dev->queue == NULL) {
printk(ERROR, "blk_alloc_queue failure!\n");
return -ENOMEM;
}
chunk_size = dev->chunk_size >> 9; //sectors
/* 将 block_make_request 注册到 q->make_request 上 */
blk_queue_make_request(dev->queue, block_make_request);
blk_queue_max_sectors(dev->queue, chunk_size);
blk_queue_hardsect_size(dev->queue, hardsect_size);
blk_queue_merge_bvec(dev->queue, block_mergeable_bvec);
dev->queue->queuedata = dev;
/* 将 block_unplug 注册到 q->unplug_fn 上 */
dev->queue->unplug_fn = block_unplug;
/* 分配一个 gendisk */
dev->gd = alloc_disk(1);
if (!dev->gd) {
prink(ERROR, "alloc_disk failure!\n");
blk_cleanup_queue(dev->queue);
return -ENOMEM;
}
dev->gd->major = block_major; /* 设备的 major 号 */
dev->gd->first_minor = minor; /* 设备的 minor 号 */
dev->gd->fops = &block_ops; /* 块设备的操作接口， open 、 close 、 ioctl */
dev->gd->queue = dev->queue; /* 块设备的请求队列 */
dev->gd->private_data = dev;
snprintf(dev->gd->disk_name, 32, dev->block_name);
dev_size = (sector_t) dev->dev_size >> 9;
set_capacity(dev->gd, dev_size); /* 设置块设备的容量 */
add_disk(dev->gd); /* 添加块设备 */
return 0;
}
注册 / 释放一个块设备
通过 register_blkdev 函数将块设备注册到 Linux 系统。示例代码如下：
static int blockdev_init(void)
{
…
block_major = register_blkdev(block_major, "blockd");
if (block_major <= 0) {
printk(ERROR, "blockd: cannot get major %d\n", block_major);
return -EFAULT;
}
…
}
通过 unregister_blkdev 函数清除一个块设备。示例代码如下：
static int blockdev_cleanup(void)
{
…
unregister_blkdev(block_major, "blockd");
…
}
make_request 函数
make_request 函数是块设备中最重要的接口函数，每个块设备都需要提供 make_request 函数。如果块设备为有请求队列的实际设备，那么 make_request 函数被注册为 __make_request ，该函数由 Linux 系统提供；反之，需要用户提供私有函数。 __make_request 函数功能在前文已述。
在用户提供的私有 make_request 函数中往往对 bio 进行过滤处理，这样的驱动在 Linux 中有 md （ raid0 、 raid1 、 raid5 ），过滤处理完毕之后，私有 make_request 函数返回 1 ，告诉 generic_make_request 函数进行 bio 转发。
