16.3. 请求处理.pdfVIP

16.3. 请求处理 16.3. 请求处理 每个块驱动的核⼼是它的请求函数. 这个函数是真正做⼯作的地⽅ --或者⾄少开始的 地⽅; 剩下的都是开 . 因此, 我们花不少时间来看在块驱动中的请求处理. ⼀个磁盘驱动的性能可能是系统整个性能的关键部分. 因此, 内核的块⼦系统编写时在 性能上考虑了很多; 它做所有可能的事情来使你的驱动从它控制的设备上获得最多. 这 是⼀个好事情, 其中它盲⽬地使能快速 I/O . 另⼀⽅⾯, 块⼦系统没必要在驱动 API 中曝 露⼤量复杂性. 有可能编写⼀个⾮常简单的请求函数( 我们将很快见到 ), 但是如果你的 驱动必须在⼀个⾼层次上操作复杂的硬件, 它可能是任何样⼦. 16.3.1. 对请求⽅法的介绍 块驱动的请求⽅法有下⾯的原型: void request(request_queue_t *queue); 这个函数被调⽤, ⽆论何时内核认为你的驱动是时候处理对设备的读, 写, 或者其他操 作. 请求函数在返回之前实际不需要完成所有的在队列中的请求; 实际上, 它可能不完 成它们任何⼀个, 对⼤部分真实设备. 它必须, 但是, 驱动这些请求并且确保它们最终被 驱动全部处理. 每个设备有⼀个请求队列. 这是因为实际的从和到磁盘的传输可能在远离内核请求它 们时发⽣, 并且因为内核需要这个灵活性来调度每个传送, 在最好的时刻(将影响磁盘上 邻近扇区的请求集合到⼀起, 例如) . 并且这个请求函数, 你可能记得, 和⼀个请求队列相 关, 当这个队列被创建时. 让我们回顾 sbull 如何创建它的队列: dev-queue = blk_init_queue(sbull_request, dev-lock); 这样, 当这个队列被创建时, 请求函数和它关联到⼀起. 我们还提供了⼀个⾃旋锁作为 队列创建过程的⼀部分. ⽆论何时我们的请求函数被调⽤, 内核持有这个锁. 结果, 请求 函数在原⼦上下⽂中运⾏; 它必须遵循所有的 5 章讨论过的原⼦代码的通⽤规则. 在你的请求函数持有锁时, 队列锁还阻⽌内核去排队任何对你的设备的其他请求. 在⼀ 些条件下, 你可能考虑在请求函数运⾏时丢弃这个锁. 如果你这样做, 但是, 你必须保证 不存取请求队列, 或者任何其他的被这个锁保护的数据结构, 在这个锁不被持有时. 你 必须重新请求这个锁, 在请求函数返回之前. 最后, 请求函数的启动(常常地)与任何⽤户空间进程之间是完全异步的. 你不能假设内 核运⾏在发起当前请求的进程上下⽂. 你不知道由这个请求提供的 I/O 缓冲是否在内核 或者⽤户空间. 因此任何类型的明确存取⽤户空间的操作都是错误的并且将肯定引起 ⿇烦. 如你将见到的, 你的驱动需要知道的关于请求的所有事情, 都包含在通过请求队 列传递给你的结构中. 16.3.2. ⼀个简单的请求⽅法 sbull 例⼦驱动提供了⼏个不同的⽅法给请求处理. 缺省地, sbull 使⽤⼀个⽅法, 称为 sbull_request , 它打算作为⼀个最简单地请求⽅法的例⼦. 别忙, 它在这⾥: static void sbull_request(request_queue_t *q) { struct request *req; while ((req = elv_next_request(q)) = NULL) { struct sbull_dev *dev = req-rq_disk-private_data if ( blk_fs_request(req)) { printk (KERN_NOTICE Skip non-fs request\n end_request(req, 0); continue; } sbull_transfer(dev, req-sector, req-current_nr_s req-buffer, rq_data_dir(req)); end_request(req, 1); } } 这个函数介绍了 struct request 结构. 我们之后将