linux下的块设备驱动(一)

时间:2023-03-08 23:37:34
linux下的块设备驱动(一)

块设备的驱动比字符设备的难,这是因为块设备的驱动和内核的联系进一步增大,但是同时块设备的访问的几个基本结构和字符还是有相似之处的。

有一句话必须记住:对于存储设备(硬盘~~带有机械的操作)而言,调整读写的顺序作用巨大,因为读写连续的扇区比分离的扇区快。

但是同时:SD卡和U盘这类设备没有机械上的限制,所以像上面说的进行连续扇区的调整显得就没有必要了。

先说一下对于硬盘这类设备的简单的驱动。

在linux的内核中,使用gendisk结构来表示一个独立的磁盘设备或者分区。这个结构中包含了磁盘的主设备号,次设备号以及设备名称。

在国嵌给的历程中,对gendisk这个结构体的填充是在simp_blkdev_init函数中完成的。在对gendisk这个结构填充之前要对其进行分配空间。具体代码如下:

simp_blkdev_disk = alloc_disk(1);
if (!simp_blkdev_disk) {
ret = -ENOMEM;
goto err_alloc_disk;
}

这里的alloc_disk函数是在内核中实现的,它后面的参数1代表的是使用次设备号的数量,这个数量是不能被修改的。

在分配好了关于gendisk的空间以后就开始对gendisk里面的成员进行填充。具体代码如下:

strcpy(simp_blkdev_disk->disk_name, SIMP_BLKDEV_DISKNAME); //宏定义simp_blkdev
simp_blkdev_disk->major = SIMP_BLKDEV_DEVICEMAJOR; //主设备号
simp_blkdev_disk->first_minor = 0; //次设备号
simp_blkdev_disk->fops = &simp_blkdev_fops; //主要结构
simp_blkdev_disk->queue = simp_blkdev_queue;
set_capacity(simp_blkdev_disk, SIMP_BLKDEV_BYTES>>9); //宏定义(16*1024*1024),实际上就是这个结构体。

在填充好gendisk这个结构以后向内核中 注册这个磁盘设备。具体代码如下:

add_disk(simp_blkdev_disk);

在LDD中说,想内核中注册设备的必须在gendisk这个结构体已经填充好了以后,我们以前的字符设备的时候也是这么做的,不知道为什么LDD在这里强调了这个。

当不需要一个磁盘的时候要释放gendisk,释放部分的代码在函数simp_blkdev_exit中实现的。具体的释放代码如下:

del_gendisk(simp_blkdev_disk);

在simp_blkdev_exit中同时还有put_disk(simp_blkdev_disk),这个是用来进行操作gendisk的引用计数。simp_blkdev_exit还实现了blk_cleanup_queue清除请求队列的这个函数。终于说到请求队列了。

在说等待队列之前先要明确几个概念:

①用户希望对硬盘数据做的事情叫做请求,这个请求和IO请求是一样的,所以IO请求来自于上层。
②每一个IO请求对应内核中的一个bio结构。

③IO调度算法可以将连续的bio(也就是用户的对硬盘数据的相邻簇的请求)合并成一个request。
④多个request就是一个请求队列,这个请求队列的作用就是驱动程序响应用户的需求的队列。

请求队列在国嵌的程序中的simp_blkdev_queue

下面先说一下硬盘这类带有机械的存储设备的驱动。

这类驱动中用户的IO请求对应于硬盘上的簇可能是连续的,可能是不连续的,连续的当然好,如果要是不连续的,那么IO调度器就会对这些BIO进行排序(例如老谢说的电梯调度算法),合并成一个request,然后再接收请求,再合并成一个request,多个request之后那么我们的请求队列就形成了,然后就可以向驱动程序提交了。

在硬盘这类的存储设备中,请求队列的初始化代码如下:

simp_blkdev_queue = blk_init_queue(simp_blkdev_do_request, NULL);

老谢说,在这种情况下首先调用的是内核中的make_requst函数,然后再调用自己定义的simp_blkdev_do_request。追了一下内核代码,会发现make_requst内核代码如下所示:

static int make_request(struct request_queue *q, struct bio * bio)

具体的就不贴了,不过可以知道这个make_request的作用就是使用IO调度器对多个bio的访问顺序进行了优化调整合并为一个request。也就是在执行完成了这个函数之后才去正式的执行内核的请求队列。

合并后的request其实还是一个结构,这个结构用来表征IO的请求,这个结构在内核中有具体的定义。

请求是一个结构,同时请求队列也是一个结构,这个请求队列在内核中的结构定义如下:

struct request_queue
{
/*
* Together with queue_head for cacheline sharing
*/
struct list_head queue_head;
struct request *last_merge;
struct elevator_queue *elevator; /*
* the queue request freelist, one for reads and one for writes
*/
struct request_list rq; request_fn_proc *request_fn;
make_request_fn *make_request_fn;
prep_rq_fn *prep_rq_fn;
unplug_fn *unplug_fn;
merge_bvec_fn *merge_bvec_fn;
prepare_flush_fn *prepare_flush_fn;
softirq_done_fn *softirq_done_fn;
rq_timed_out_fn *rq_timed_out_fn;
dma_drain_needed_fn *dma_drain_needed;
lld_busy_fn *lld_busy_fn; /*
* Dispatch queue sorting
*/
sector_t end_sector;
struct request *boundary_rq; /*
* Auto-unplugging state
*/
struct timer_list unplug_timer;
int unplug_thresh; /* After this many requests */
unsigned long unplug_delay; /* After this many jiffies */
struct work_struct unplug_work; struct backing_dev_info backing_dev_info; /*
* The queue owner gets to use this for whatever they like.
* ll_rw_blk doesn't touch it.
*/
void *queuedata; /*
* queue needs bounce pages for pages above this limit
*/
gfp_t bounce_gfp; /*
* various queue flags, see QUEUE_* below
*/
unsigned long queue_flags; /*
* protects queue structures from reentrancy. ->__queue_lock should
* _never_ be used directly, it is queue private. always use
* ->queue_lock.
*/
spinlock_t __queue_lock;
spinlock_t *queue_lock; /*
* queue kobject
*/
struct kobject kobj; /*
* queue settings
*/
unsigned long nr_requests; /* Max # of requests */
unsigned int nr_congestion_on;
unsigned int nr_congestion_off;
unsigned int nr_batching; void *dma_drain_buffer;
unsigned int dma_drain_size;
unsigned int dma_pad_mask;
unsigned int dma_alignment; struct blk_queue_tag *queue_tags;
struct list_head tag_busy_list; unsigned int nr_sorted;
unsigned int in_flight[2]; unsigned int rq_timeout;
struct timer_list timeout;
struct list_head timeout_list; struct queue_limits limits; /*
* sg stuff
*/
unsigned int sg_timeout;
unsigned int sg_reserved_size;
int node;
#ifdef CONFIG_BLK_DEV_IO_TRACE
struct blk_trace *blk_trace;
#endif
/*
* reserved for flush operations
*/
unsigned int ordered, next_ordered, ordseq;
int orderr, ordcolor;
struct request pre_flush_rq, bar_rq, post_flush_rq;
struct request *orig_bar_rq; struct mutex sysfs_lock; #if defined(CONFIG_BLK_DEV_BSG)
struct bsg_class_device bsg_dev;
#endif
};

LDD说,请求队列实现了一个插入接口,这个接口允许使用多个IO调度器,大部分IO调度器批量累计IO请求,并将它们排列为递增或者递减的顺序提交给驱动。

多个连续的bio会合并成为一个request,多个request就成为了一个请求队列,这样bio的是直接的也是最基本的请求,bio这个结构的定义如下:

struct bio { sector_t            bi_sector;
struct bio *bi_next; /* request queue link */
struct block_device *bi_bdev; /* target device */
unsigned long bi_flags; /* status, command, etc */ unsigned long bi_rw; /* low bits: r/w, high: priority */
unsigned int bi_vcnt; /* how may bio_vec's */
unsigned int bi_idx; /* current index into bio_vec array */
unsigned int bi_size; /* total size in bytes */
unsigned short bi_phys_segments; /* segments after physaddr coalesce*/ unsigned short bi_hw_segments; /* segments after DMA remapping */ unsigned int bi_max; /* max bio_vecs we can hold used as index into pool */ struct bio_vec *bi_io_vec; /* the actual vec list */
bio_end_io_t *bi_end_io; /* bi_end_io (bio) */
atomic_t bi_cnt; /* pin count: free when it hits zero */ void *bi_private;
bio_destructor_t *bi_destructor; /* bi_destructor (bio) */ };

需要注意的是,在bio这个结构中最重要的是bio.vec这个结构。同时还有许多操作bio的宏,这些都是内核给实现好了的。

请求队列的实现:

首先使用 while ((req = elv_next_request(q)) != NULL)进行循环检测,看看到底传来的IO请求是个什么。

然后进行读写区域的判定:

if ((req->sector + req->current_nr_sectors) << 9
> SIMP_BLKDEV_BYTES) {
printk(KERN_ERR SIMP_BLKDEV_DISKNAME
": bad request: block=%llu, count=%u\n",
(unsigned long long)req->sector,
req->current_nr_sectors);
//结束本次请求。
end_request(req, 0);
continue;
}

在进行读写区域的判定的时候涉及到了很多linux的编程习惯。

sector表示要访问的第一个扇区。

current_nr_sectors表示预计访问扇区的数目。

这里的左移九位其实就是乘以512。

这样((req->sector + req->current_nr_sectors) << 9就计算出可以预计要访问的扇区的大小。进行了一次判断。

如果上面的判断没有超出范围,那么就可以对请求的这一部分块设备进行操作了。

simp_blkdev_disk = alloc_disk(1);
if (!simp_blkdev_disk) {
ret = -ENOMEM;
goto err_alloc_disk;
} strcpy(simp_blkdev_disk->disk_name, SIMP_BLKDEV_DISKNAME);
simp_blkdev_disk->major = SIMP_BLKDEV_DEVICEMAJOR;
simp_blkdev_disk->first_minor = 0;
simp_blkdev_disk->fops = &simp_blkdev_fops;
simp_blkdev_disk->queue = simp_blkdev_queue;
set_capacity(simp_blkdev_disk, SIMP_BLKDEV_BYTES>>9);
add_disk(simp_blkdev_disk); return 0;

关于gendisk结构的内存分配和成员的填充和硬盘类块设备是一样的。

由于SD卡和U盘属于一类非机械类的设备,所以我们不需要那么复杂的调度算法,也就是不需要把io请求进行排序,所以我们需要自己为自己分配一个请求队列。具体代码如下:

simp_blkdev_queue = blk_alloc_queue(GFP_KERNEL);

需要注意一下的是在硬盘类块设备的驱动中这个函数的原型是blk_init_queue(simp_blkdev_do_request, NULL);

在这种情况下其实并没有调用内核的make_request(这个函数的功能上文说过),也就是说我们接下来要绑定的simp_blkdev_make_request这个函数和make_request是同一级别的函数。这里就没有涉及到算法调度的问题了。

然后需要进行的工作是:绑定制造请求函数和请求队列。具体代码如下:

blk_queue_make_request(simp_blkdev_queue, simp_blkdev_make_request);

把gendisk的结构成员都添加好了以后就可以执行add_disk(simp_blkdev_disk);这个函数把这块分区添加进内核了。

整体列出制造请求部分的函数。

//这个条件是在判断当前正在运行的内核版本。
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 24)
bio_endio(bio, 0, -EIO);
#else
bio_endio(bio, -EIO);
#endif
return 0;
} dsk_mem = simp_blkdev_data + (bio->bi_sector << 9); //遍历
bio_for_each_segment(bvec, bio, i) {
void *iovec_mem; switch (bio_rw(bio)) {
case READ:
case READA:
iovec_mem = kmap(bvec->bv_page) + bvec->bv_offset;
memcpy(iovec_mem, dsk_mem, bvec->bv_len);
kunmap(bvec->bv_page);
break;
case WRITE:
iovec_mem = kmap(bvec->bv_page) + bvec->bv_offset;
memcpy(dsk_mem, iovec_mem, bvec->bv_len);
kunmap(bvec->bv_page);
break;
default:
printk(KERN_ERR SIMP_BLKDEV_DISKNAME
": unknown value of bio_rw: %lu\n",
bio_rw(bio));
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 24)
bio_endio(bio, 0, -EIO);
#else
bio_endio(bio, -EIO);
#endif
return 0;
}
dsk_mem += bvec->bv_len;
} #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 24)
bio_endio(bio, bio->bi_size, 0);
#else
bio_endio(bio, 0);
#endif return 0;
}