块设备的操作函数并没有类似于字符驱动中的read 和write函数,要实现读写操作,只能在请求处理函数中实现。这就分为两种,是否要使用请求队列,请求队列的主要作用是管理和调度IO请求。在以下情况中,一般需要用到请求队队列:
- 多任务环境:多个任务同时对存储设备进行读写,请求队列可以对IO请求进行排序和调度
- 磁盘优化:磁盘是一种机械设备,其IO操作需要进行磁盘寻道等操作,非常耗时,请求队列可以将多个IO请求进行合并,可以减少磁盘的寻道次数,提高磁盘的吞吐量。
因此,本篇的重点便是使用请求队列来实现块设备的读写操作。
目录
一、请求处理函数的触发条件
二、从请求队列获取请求
三、开始进行读写操作
1、请求的结构
2、相关API
四、关闭请求
五、完整代码
一、请求处理函数的触发条件
若要对块设备进行读写操作,需要触发请求处理函数,随后块设备驱动才会调度并处理请求。那么在什么情况下会触发请求处理函数?以下是读写操作的常见触发条件。
读操作
一般涉及到访问文件内容、文件属性、文件权限的时候,会触发请求处理函数中的读操作。
① 读取数据
当应用程序执行文件读取操作(如 read 函数)时,它会向文件系统发送读取请求,并触发请求处理函数中的读操作。每一个请求内包含源数据(块设备扇区地址、读取字节数)以及目的地址(内存页地址、页偏移)。文件系统从块设备读取相应的文件块数据,并将其返回给应用程序。
② 目录遍历
当应用程序执行目录遍历操作(如 opendir、readdir 函数等)时,文件系统会在磁盘上读取目录的元数据,并返回给应用程序。
③打开文件
当应用程序打开一个文件时,文件系统需要读取磁盘上的文件元数据信息,如文件大小、访问权限等,以供应用程序使用。
写操作
一般涉及到文件内容的更新、文件创建等操作时,会触发请求处理函数中的写操作。
① 文件内容写入(追加、更新)
文件内容的写入(write)和追加(append)会向文件系统发送写入请求,并触发请求触发函数中的写操作。每一个请求内包含源数据(内存页地址、页偏移)以及目的地址(块设备扇区地址),文件系统会将应用程序提供的数据写入到指定扇区。
此外,除了文件内容的更新,文件属性(如访问权限)的更新也会触发请求处理函数。
② 文件创建
当应用程序创建一个新文件时,它会向文件系统发送创建文件的请求,并触发请求处理函数中的写操作。文件系统在磁盘上为新文件分配空间,并更新文件的元数据信息。
二、从请求队列获取请求
接下来便是正式开始实现请求处理函数,函数的形参为请求队列,对此,下面的第一步便是从请求队列中获取请求。涉及的API 在 <linux/blkdev.h> 中
void request_handle(struct request_queue *q);
① 方式一:获取 + 开启请求
正常来说,获取请求包含两步,第一步是获取请求,使用的API为 blk_peek_request
/**
* @param q 请求队列
* @return 成功返回获取到的请求结构体地址,失败返回 NULL
*/
struct request *blk_peek_request(struct request_queue *q);
获取到请求以后,还没结束,需要开启请求,目的是将通知硬件设备开始处理当前请求,同时将当前请求标记为启动状态,以确保请求在处理的过程中不会被打断。其他还有数据预处理、设备准备等原因。
/**
* @param rq 获取到的请求
*/
void blk_start_request(struct request *rq);
② 方式二:一步到位
Linux内核提供了获取 + 开启一步到位的方式,使用的API为 blk_fetch_request,该函数其实就是对上述两个函数的使用做了一层封装。
/**
* @param q 请求队列
* @return 成功返回获取到的请求结构体地址,失败返回 NULL
*/
struct request *blk_fetch_request(struct request_queue *q);
/*
struct request *blk_fetch_request(struct request_queue *q)
{
struct request *rq;
rq = blk_peek_request(q);
if (rq)
blk_start_request(rq);
return rq;
}
*/
三、开始进行读写操作
在开始读写操作之前,需要先了解每一个请求的结构,因为既然要进行读写操作,我们需要知道源数据地址、目的地址、操作的字节数等信息。
1、请求的结构
每个request 中保存了多个 bio,bio保存着最终要读写的数据、地址等信息。bio 中的 bvec_iter 保存了块设备扇区起始地址、扇区大小等信息,bio 中的 bio_vec 保存了 RAM 页地址、剩余页长度以及页偏移等信息。
下面是 bio、bio_iter 和 bio_vec 三者之间的关系
2、相关API
获得扇区起始地址
/**
* @param rq 指向请求结构体的指针
* @return 成功返回获取到的扇区起始地址
*/
sector_t blk_rq_pos(const struct request *rq);
获取请求所涉及的数据长度
/**
* @param rq 指向请求结构体的指针
* @return 成功返回数据长度,单位:字节
*/
unsigned int blk_rq_bytes(const struct request *rq);
获取指定数据页的线性地址,即 RAM 中的起始页地址
/**
* @param bio 指向bio结构体的指针
* @return 成功返回指向指定数据页的地址
*/
void *bio_data(struct bio *bio);
获取当前请求的数据传输方向(读操作、写操作)
/**
* @param rq 指向请求结构体的指针
* @return 返回数据传输方向。可以是 READ / WRITE
*/
int rq_data_dir(struct request *rq);
四、关闭请求
与前面开启请求相对应,开启请求后将当前请求标记为开启状态,以确保在处理请求的过程中不会被打断;关闭请求意味着该请求的数据传输和相关操作已经完成,主要目的有两点:
- 通知请求完成:通知相关的应用程序或调用者操作已经结束,允许继续执行后续的操作
- 资源释放:在请求处理完成后,需要释放请求所占用的内存和其他资源,以便系统能够重新利用这些资源。
这里可以使用 __blk_end_request_cur 或者 blk_end_request_cur,两个函数的使用方法完全一样,他们之间的区别在于
① __blk_end_request_cur
__blk_end_request_cur是一个异步函数,它会立即结束当前的 I/O 请求,并触发相应的回调函数(例如,end_io)来进行后续处理。这意味着调用 __blk_end_request_cur 并不会等待请求的处理完成,而是立即返回,将请求的处理交给后续的回调函数来处理。
② blk_end_request_cur
blk_end_request_cur 与上面相反,是一个同步函数,它会等待当前的 I/O 请求的处理完成,并在处理完成后返回。它会等待直到请求的 end_io 回调函数执行完毕,或者出现超时或错误等情况。因此,在调用 blk_end_request_cur 的过程中,它会阻塞当前的执行线程,直到请求处理完成。
/**
* @param rq 指向请求结构体的指针
* @param error 代表请求处理结果,
* - 若请求处理成功,应该将 error 设置为 0
* - 若请求处理失败,则可以设置为其他非零值。
*/
bool __blk_end_request_cur(struct request *rq, int error);
五、完整代码
将驱动代码重新编译并加入到内核,输入 fdisk -l,我们会发现请求处理函数被触发了,因为 fdisk -l 用于列出当前系统中所有的磁盘分区信息,在扫描设备的过程中,会涉及块设备的访问和信息读取,这就导致了请求处理函数被触发。
void request_handle(struct request_queue *q)
{
printk("请求处理函数被触发!\n");
struct request* req; // 处理请求
int errors = 0; // 请求处理状态
sector_t start = 0; // 操作扇区的起始地址
int len = 0;
while ((req = blk_fetch_request(q)) != NULL)
{
// 获得扇区起始地址
start = blk_rq_pos(req);
// 当前请求所涉及的字节数
len = blk_rq_cur_bytes(req);
// 获得bio结构体中的缓冲区指针
void* buffer = bio_data(req->bio);
// 判断是读操作还是写操作
if (rq_data_dir(req) == READ)
{
memcpy((uint8_t*)buffer, blkdev.diskbuf, len);
printk("从块设备读数据\n");
}
else if(rq_data_dir(req) == WRITE)
{
memcpy(blkdev.diskbuf, (uint8_t*)buffer, len);
printk("向块设备写数据\n");
}
// 结束当前请求
__blk_end_request_cur(req, errors);
}
}