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;
}
