Linux那些事儿之我是Block层(6)浓缩就是精华?(三)

第三个,blk_register_queue().

   4079 int blk_register_queue(struct gendisk *disk)

   4080 {

   4081         int ret;

   4082

   4083         request_queue_t *q = disk->queue;

   4084

   4085         if (!q || !q->request_fn)

   4086                 return -ENXIO;

   4087

   4088         q->kobj.parent = kobject_get(&disk->kobj);

   4089

   4090         ret = kobject_add(&q->kobj);

   4091         if (ret < 0)

   4092                 return ret;

   4093

   4094         kobject_uevent(&q->kobj, KOBJ_ADD);

   4095

   4096         ret = elv_register_queue(q);

   4097         if (ret) {

   4098                 kobject_uevent(&q->kobj, KOBJ_REMOVE);

   4099                 kobject_del(&q->kobj);

   4100                 return ret;

   4101         }

   4102

   4103         return 0;

   4104 }

首先,4090行这个kobject_add很好解释,在/sys/block/sda/目录下面又多一个子目录而已,但问题是,这个q究竟是什么?这里我们把disk->queue赋给了它,而disk->queue又是什么呢?回过头去看sd_probe(),当时我们有这么一句,

   1662         gd->queue = sdkp->device->request_queue;

而sdkp是struct scsi_disk结构体指针,其device成员是struct scsi_device指针,那么这个request_queue呢?是struct request_queue结构体指针,表示的是一个请求队列.但它是从哪儿来的呢?一路走来的兄弟们可能会猜到,事实上scsi设备驱动和usb设备驱动有一点是相同的,在它们的probe函数被调用之前,核心层实际上已经为它们做了许多工作了.比如usb那边就是为usb设备申请usb_device结构体变量,而这边也是如此,申请了scsi_device结构体变量,为它的一些成员赋好了值,这其中就包括了这个请求队列.

准确地说,在scsi总线扫描的时候,每当探测到一个设备,就会调用scsi_alloc_sdev()函数,这个函数我们无意多说,但是可以告诉你的是,它会调用一个叫做scsi_alloc_queue()的函数.而这个函数涉及到很多block层提供的函数,所以我们不得不从这里开始看起,来自drivers/scsi/scsi_lib.c:

   1569 struct request_queue *__scsi_alloc_queue(struct Scsi_Host *shost,

   1570                                          request_fn_proc *request_fn)

   1571 {

   1572         struct request_queue *q;

   1573

   1574         q = blk_init_queue(request_fn, NULL);

   1575         if (!q)

   1576                 return NULL;

   1577

   1578         blk_queue_max_hw_segments(q, shost->sg_tablesize);

   1579         blk_queue_max_phys_segments(q, SCSI_MAX_PHYS_SEGMENTS);

   1580         blk_queue_max_sectors(q, shost->max_sectors);

   1581         blk_queue_bounce_limit(q, scsi_calculate_bounce_limit(shost));

   1582         blk_queue_segment_boundary(q, shost->dma_boundary);

   1583

   1584         if (!shost->use_clustering)

   1585                 clear_bit(QUEUE_FLAG_CLUSTER, &q->queue_flags);

   1586         return q;

   1587 }

   1588 EXPORT_SYMBOL(__scsi_alloc_queue);

   1589

   1590 struct request_queue *scsi_alloc_queue(struct scsi_device *sdev)

   1591 {

   1592         struct request_queue *q;

   1593

   1594         q = __scsi_alloc_queue(sdev->host, scsi_request_fn);

   1595         if (!q)

   1596                 return NULL;

   1597

   1598         blk_queue_prep_rq(q, scsi_prep_fn);

   1599         blk_queue_issue_flush_fn(q, scsi_issue_flush_fn);

   1600         blk_queue_softirq_done(q, scsi_softirq_done);

   1601         return q;

   1602 }

这两个函数因为调用关系所以一并贴了出来.

我们首先要看的很自然就是blk_init_queue(),它来自block/ll_rw_blk.c:

   1860 /**

   1861  * blk_init_queue  - prepare a request queue for use with a block device

   1862  * @rfn:  The function to be called to process requests that have been

   1863  *        placed on the queue.

   1864  * @lock: Request queue spin lock

   1865  *

   1866  * Description:

   1867  *    If a block device wishes to use the standard request handling procedures,

   1868  *    which sorts requests and coalesces adjacent requests, then it must

   1869  *    call blk_init_queue().  The function @rfn will be called when there

   1870  *    are requests on the queue that need to be processed.  If the device

   1871  *    supports plugging, then @rfn may not be called immediately when requests

   1872  *    are available on the queue, but may be called at some time later instead.

   1873  *    Plugged queues are generally unplugged when a buffer belonging to one

   1874  *    of the requests on the queue is needed, or due to memory pressure.

   1875  *

   1876  *    @rfn is not required, or even expected, to remove all requests off the

   1877  *    queue, but only as many as it can handle at a time.  If it does leave

   1878  *    requests on the queue, it is responsible for arranging that the requests

   1879  *    get dealt with eventually.

   1880  *

   1881  *    The queue spin lock must be held while manipulating the requests on the

   1882  *    request queue; this lock will be taken also from interrupt context, so irq

   1883  *    disabling is needed for it.

   1884  *

   1885  *    Function returns a pointer to the initialized request queue, or NULL if

   1886  *    it didn't succeed.

   1887  *

   1888  * Note:

   1889  *    blk_init_queue() must be paired with a blk_cleanup_queue() call

   1890  *    when the block device is deactivated (such as at module unload).

   1891  **/

   1892

   1893 request_queue_t *blk_init_queue(request_fn_proc *rfn, spinlock_t *lock)

   1894 {

   1895         return blk_init_queue_node(rfn, lock, -1);

   1896 }

   1897 EXPORT_SYMBOL(blk_init_queue);

   1898

   1899 request_queue_t *

   1900 blk_init_queue_node(request_fn_proc *rfn, spinlock_t *lock, int node_id)

   1901 {

   1902         request_queue_t *q = blk_alloc_queue_node(GFP_KERNEL, node_id);

   1903

   1904         if (!q)

   1905                 return NULL;

   1906

   1907         q->node = node_id;

   1908         if (blk_init_free_list(q)) {

   1909                 kmem_cache_free(requestq_cachep, q);

   1910                 return NULL;

   1911         }

   1912

   1913         /*

   1914          * if caller didn't supply a lock, they get per-queue locking with

   1915          * our embedded lock

   1916          */

   1917         if (!lock) {

   1918                 spin_lock_init(&q->__queue_lock);

   1919                 lock = &q->__queue_lock;

   1920         }

   1921

   1922         q->request_fn           = rfn;

   1923         q->prep_rq_fn           = NULL;

   1924         q->unplug_fn            = generic_unplug_device;

   1925         q->queue_flags          = (1 << QUEUE_FLAG_CLUSTER);

   1926         q->queue_lock           = lock;

   1927

   1928         blk_queue_segment_boundary(q, 0xffffffff);

   1929

   1930         blk_queue_make_request(q, __make_request);

   1931         blk_queue_max_segment_size(q, MAX_SEGMENT_SIZE);

   1932

   1933         blk_queue_max_hw_segments(q, MAX_HW_SEGMENTS);

   1934         blk_queue_max_phys_segments(q, MAX_PHYS_SEGMENTS);

   1935

   1936         q->sg_reserved_size = INT_MAX;

   1937

   1938         /*

   1939          * all done

   1940          */

   1941         if (!elevator_init(q, NULL)) {

   1942                 blk_queue_congestion_threshold(q);

   1943                 return q;

   1944         }

   1945

   1946         blk_put_queue(q);

   1947         return NULL;

   1948 }

别看这些函数都很可怕,真正我们目前需要关注的其实只是其中的某几个而已.它们这个blk_alloc_queue_node和elevator_init().前者来自block/ll_rw_blk.c,后者则来自block/elevator.c:

   1836 request_queue_t *blk_alloc_queue_node(gfp_t gfp_mask, int node_id)

   1837 {

   1838         request_queue_t *q;

   1839

   1840         q = kmem_cache_alloc_node(requestq_cachep, gfp_mask, node_id);

   1841         if (!q)

   1842                 return NULL;

   1843

   1844         memset(q, 0, sizeof(*q));

   1845         init_timer(&q->unplug_timer);

   1846

   1847         snprintf(q->kobj.name, KOBJ_NAME_LEN, "%s", "queue");

   1848         q->kobj.ktype = &queue_ktype;

   1849         kobject_init(&q->kobj);

   1850

   1851         q->backing_dev_info.unplug_io_fn = blk_backing_dev_unplug;

   1852         q->backing_dev_info.unplug_io_data = q;

   1853

   1854         mutex_init(&q->sysfs_lock);

   1855

   1856         return q;

   1857 }

还记得本故事最早时期讲的那个blk_dev_init吧,当时我们调用kmem_cache_create()申请了一个内存池request_cachep,现在就该用它了.从这个池子里申请了一个struct request_queue_t结构体的空间,给了指针q,然后1844行初始化为0.而1847行让q的kobj.name等于”queue”,这就是为什么今后我们在/sys/block/sda/目录下面能看到一个叫做”queue”的目录.

[root@localhost ~]# ls /sys/block/sda/

capability  device   queue  removable  sda10  sda12  sda14  sda2  sda5  sda7  sda9  slaves  subsystem dev         holders  range  sda1       sda11  sda13  sda15  sda3  sda6  sda8  size  stat    uevent

而这个queue目录下面的内容是什么呢?

[root@localhost ~]# ls /sys/block/sda/queue/

iosched  max_hw_sectors_kb  max_sectors_kb  nr_requests  read_ahead_kb  scheduler

这几个文件从哪来的?注意1848行那个queue_ktype.

   4073 static struct kobj_type queue_ktype = {

   4074         .sysfs_ops      = &queue_sysfs_ops,

   4075         .default_attrs  = default_attrs,

   4076         .release        = blk_release_queue,

   4077 };

如果你真懂设备模型,那么你一定会去查看这个default_attrs是什么,

   3988 static struct queue_sysfs_entry queue_requests_entry = {

   3989         .attr = {.name = "nr_requests", .mode = S_IRUGO | S_IWUSR },

   3990         .show = queue_requests_show,

   3991         .store = queue_requests_store,

   3992 };

   3993

   3994 static struct queue_sysfs_entry queue_ra_entry = {

   3995         .attr = {.name = "read_ahead_kb", .mode = S_IRUGO | S_IWUSR },

   3996         .show = queue_ra_show,

   3997         .store = queue_ra_store,

   3998 };

   3999

   4000 static struct queue_sysfs_entry queue_max_sectors_entry = {

   4001         .attr = {.name = "max_sectors_kb", .mode = S_IRUGO | S_IWUSR },

   4002         .show = queue_max_sectors_show,

   4003         .store = queue_max_sectors_store,

   4004 };

   4005

   4006 static struct queue_sysfs_entry queue_max_hw_sectors_entry = {

   4007         .attr = {.name = "max_hw_sectors_kb", .mode = S_IRUGO },

   4008         .show = queue_max_hw_sectors_show,

   4009 };

   4010

   4011 static struct queue_sysfs_entry queue_iosched_entry = {

   4012         .attr = {.name = "scheduler", .mode = S_IRUGO | S_IWUSR },

   4013         .show = elv_iosched_show,

   4014         .store = elv_iosched_store,

   4015 };

   4016

   4017 static struct attribute *default_attrs[] = {

   4018         &queue_requests_entry.attr,

   4019         &queue_ra_entry.attr,

   4020         &queue_max_hw_sectors_entry.attr,

   4021         &queue_max_sectors_entry.attr,

   4022         &queue_iosched_entry.attr,

   4023         NULL,

   4024 };

看到了吗?是一个指针数组,按照设备模型的理论来说,这些就是定义了一些属性,kobject的属性,看到这些属性的name是不是和刚才那个queue目录下面的文件名字是一样的?没错,queue目录下面每个文件就是和这里这些属性一一对应的.不过有一个东西例外,它就是iosched,这不是一个文件,这是一个目录.

[root@localhost ~]# ls -l /sys/block/sdf/queue/

total 0

drwxr-xr-x 2 root root    0 Dec 14 02:46 iosched

-r--r--r-- 1 root root 4096 Dec 14 06:21 max_hw_sectors_kb

-rw-r--r-- 1 root root 4096 Dec 14 06:21 max_sectors_kb

-rw-r--r-- 1 root root 4096 Dec 14 06:21 nr_requests

-rw-r--r-- 1 root root 4096 Dec 14 06:21 read_ahead_kb

-rw-r--r-- 1 root root 4096 Dec 14 06:21 scheduler

[root@localhost ~]# ls /sys/block/sdf/queue/iosched/

back_seek_max      fifo_expire_async  quantum      slice_async_rq  slice_sync back_seek_penalty  fifo_expire_sync   slice_async  slice_idle

关于这个目录,我们来看另一个函数,elevator_init(),来自block/elevator.c:

    220 int elevator_init(request_queue_t *q, char *name)

    221 {

    222         struct elevator_type *e = NULL;

    223         struct elevator_queue *eq;

    224         int ret = 0;

    225         void *data;

    226

    227         INIT_LIST_HEAD(&q->queue_head);

    228         q->last_merge = NULL;

    229         q->end_sector = 0;

    230         q->boundary_rq = NULL;

    231

    232         if (name && !(e = elevator_get(name)))

    233                 return -EINVAL;

    234

    235         if (!e && *chosen_elevator && !(e = elevator_get(chosen_elevator)))

    236                 printk("I/O scheduler %s not found/n", chosen_elevator);

    237

    238         if (!e && !(e = elevator_get(CONFIG_DEFAULT_IOSCHED))) {

    239                 printk("Default I/O scheduler not found, using no-op/n");

    240                 e = elevator_get("noop");

    241         }

    242

    243         eq = elevator_alloc(q, e);

    244         if (!eq)

    245                 return -ENOMEM;

    246

    247         data = elevator_init_queue(q, eq);

    248         if (!data) {

    249                 kobject_put(&eq->kobj);

    250                 return -ENOMEM;

    251         }

    252

    253         elevator_attach(q, eq, data);

    254         return ret;

    255 }

重点关注elevator_alloc().

    179 static elevator_t *elevator_alloc(request_queue_t *q, struct elevator_type *e)

    180 {

    181         elevator_t *eq;

    182         int i;

    183

    184         eq = kmalloc_node(sizeof(elevator_t), GFP_KERNEL, q->node);

    185         if (unlikely(!eq))

    186                 goto err;

    187

    188         memset(eq, 0, sizeof(*eq));

    189         eq->ops = &e->ops;

    190         eq->elevator_type = e;

    191         kobject_init(&eq->kobj);

    192         snprintf(eq->kobj.name, KOBJ_NAME_LEN, "%s", "iosched");

    193         eq->kobj.ktype = &elv_ktype;

    194         mutex_init(&eq->sysfs_lock);

    195

    196         eq->hash = kmalloc_node(sizeof(struct hlist_head) * ELV_HASH_ENTRIES,

    197                                         GFP_KERNEL, q->node);

    198         if (!eq->hash)

    199                 goto err;

    200

    201         for (i = 0; i < ELV_HASH_ENTRIES; i++)

    202                 INIT_HLIST_HEAD(&eq->hash[i]);

    203

    204         return eq;

    205 err:

    206         kfree(eq);

    207         elevator_put(e);

    208         return NULL;

    209 }

无非就是申请一个struct elevator_t结构体变量的空间并且初始化为0.

而真正引发我们兴趣的是192行,很显然,就是因为这里把eq的kobj的name设置为”iosched”,才会让我们在queue目录下看到那个”iosched”子目录.

而这个子目录下那些乱七八糟的文件又来自哪里呢?正是下面这个elv_register_queue()函数,这个我们在blk_register_queue()中调用的函数.

    931 int elv_register_queue(struct request_queue *q)

    932 {

    933         elevator_t *e = q->elevator;

    934         int error;

    935

    936         e->kobj.parent = &q->kobj;

    937

    938         error = kobject_add(&e->kobj);

    939         if (!error) {

    940                 struct elv_fs_entry *attr = e->elevator_type->elevator_attrs;

    941                 if (attr) {

    942                         while (attr->attr.name) {

    943                                 if (sysfs_create_file(&e->kobj, &attr->attr))

    944                                         break;

    945                                 attr++;

    946                         }

    947                 }

    948                 kobject_uevent(&e->kobj, KOBJ_ADD);

    949         }

    950         return error;

    951 }

936行保证了,iosched是出现在queue目录下而不是出现在别的地方,而942行这个while循环则是创建iosched目录下面那么多文件的.我们先来看这个attr到底是什么,这里它指向了e->elevator_type->elevator_attrs,而在刚才那个elevator_alloc()函数中,190行,我们看到了eq->elevator_type被赋上了e,回溯至elevator_init(),我们来看e究竟是什么.

首先,当我们在blk_init_queue_node()中调用elevator_init的时候,传递的第二个参数是NULL,即name指针是NULL.

那么很明显,235行和238行这两个if语句对于e的取值至关重要.而到了现在,传说中的电梯算法也不得不介绍了.

话说,在Linux中如果你要读写一些磁盘数据,你需要创建一个block device request.这个request基本上描述了请求的扇区以及操作的类型.(即,你是要读还是要写)而对于一个设备来说,请求多了自然就应该使用某种数据结构来存储它们,很显然我们会使用队列,于是,Linux中为每个块设备准备了一个请求队列,即所谓的request queue.每接收到一个请求,就把它插入到request queue这个队列中去.

那么这里有一个问题,比如说队列里有好几十个请求,那么谁先执行谁后执行呢?是不是谁先提交就先执行谁?不是.这里需要调度,否则磁盘的性能就会很糟糕.

比如说英超联赛,拿我家切尔西来举例,一个赛季38场英超联赛,如果说赛程是一场主场一场客场一场主场一场客场一场主场一场客场…,那么这样的赛程一定是很糟糕的,因为球员要不停的奔波,每踢一场比赛就得进行一次车旅劳顿,球员纷纷疲于奔命,状态根本无法保证,那么比这个好点的赛程是什么?比如,连续几个主场,连续几个客场,那么至少在连续的这几个主场作战的期间球员们不用把体力消耗在旅途中,而在连续的几个客场中,怎么安排又有区别了,假设有这样四个连续的客场,对手分别是曼联,曼城,利物浦,埃弗顿,那么理想的赛程是,踢曼联和踢曼城这两场相邻,踢利物浦和踢埃弗顿这两场相邻,这样旅途耗费时间最少,那么最恶劣的赛程是什么呢?先去曼彻斯特踢曼联,然后去利物浦踢利物浦,然后又折回曼彻斯特踢曼城,再然后又杀回利物浦去战埃弗顿,很显然这样的赛程是最艰苦的,这就是所谓的魔鬼赛程.所以赛程的好坏很有可能影响一支球队的战绩.

而磁盘调度也是如此.磁头的移来移去是很费时间的,如果我这一次要读的扇区在”曼彻斯特”,下一次要读的扇区又在”利物浦”,下下次又回到”曼彻斯特”,然后又去到”利物浦”,这样显然会影响磁盘的性能.所以如果我们能够改变这种顺序,能够让前后两次访问的扇区尽量在相邻的位置,那么毫无疑问将提高磁盘的性能.而完成这项工作的叫做IO调度器.(The I/O Scheduler)

IO调度器的总体目标是希望让磁头能够总是往一个方向移动,移动到底了再往反方向走,这恰恰就是现实生活中的电梯模型,所以IO调度器也被叫做电梯.(elevator)而相应的算法也就被叫做电梯算法.而Linux中IO调度的电梯算法有好几种,一个叫做as(Anticipatory),一个叫做cfq(Complete Fairness Queueing),一个叫做deadline,还有一个叫做noop(No Operation).具体使用哪种算法我们可以在启动的时候通过内核参数elevator来指定.比如在我的grub配置文件中就这样设置过:

###Don't change this comment - YaST2 identifier: Original name: linux###

title Linux

    kernel (hd0,0)/vmlinuz root=/dev/sda3 selinux=0 resume=/dev/sda2 splash=silent elevator=cfq showopts console=ttyS0,9600 console=tty0

    initrd (hd0,0)/initrd

让elevator=cfq,因此cfq算法将是我们的IO调度器所采用的算法.而另一方面我们也可以单独的为某个设备指定它所采用的IO调度算法,这就通过修改在/sys/block/sda/queue/目录下面的scheduler文件.比如我们可以先看一下我的这块硬盘:

[root@localhost ~]# cat /sys/block/sda/queue/scheduler

noop anticipatory deadline [cfq]

可以看到我们这里采用的是cfq.

Ok,现在还不是细说这几种算法的时刻,我们接着刚才的话题,还看elevator_init().

首先chosen_elevator是定义于block/elevator.c中的一个字符串.

    160 static char chosen_elevator[16];

这个字符串就是用来记录启动参数elevator的.如果没有设置,那就没有值.

而CONFIG_DEFAULT_IOSCHED是一个编译选项.它就是一字符串,在编译内核的时候设置的,比如我的是cfq.

    119 CONFIG_DEFAULT_IOSCHED="cfq"

你当然也可以选择其它三个,看个人喜好了,喜欢哪个就选择哪个.我的建议是,喜欢的就要拥有她,不要害怕结果.总之这个字符串会传递给elevator_get这个来自block/elevator.c的函数:

    133 static struct elevator_type *elevator_get(const char *name)

    134 {

    135         struct elevator_type *e;

    136

    137         spin_lock(&elv_list_lock);

    138

    139         e = elevator_find(name);

    140         if (e && !try_module_get(e->elevator_owner))

    141                 e = NULL;

    142

    143         spin_unlock(&elv_list_lock);

    144

    145         return e;

    146 }

这里elevator_find()也来自同一个文件.

    112 static struct elevator_type *elevator_find(const char *name)

    113 {

    114         struct elevator_type *e;

    115         struct list_head *entry;

    116

    117         list_for_each(entry, &elv_list) {

    118

    119                 e = list_entry(entry, struct elevator_type, list);

    120

    121                 if (!strcmp(e->elevator_name, name))

    122                         return e;

    123         }

    124

    125         return NULL;

    126 }

&elv_list是什么?首先,复旦南区后门卖炒饭的那几对夫妻都知道elv_list一定是一个链表.但是这张链表具体是什么内容呢?事实上,甭管是这四种算法中的哪一种,在正式登台演出之前,都需要做一些初始化,初始化过程中最本质的一项工作就是调用elv_register()函数来注册自己.而这个注册主要就是往elv_list这张链表里登记.

    965 int elv_register(struct elevator_type *e)

    966 {

    967         char *def = "";

    968

    969         spin_lock(&elv_list_lock);

    970         BUG_ON(elevator_find(e->elevator_name));

    971         list_add_tail(&e->list, &elv_list);

    972         spin_unlock(&elv_list_lock);

    973

    974         if (!strcmp(e->elevator_name, chosen_elevator) ||

    975                         (!*chosen_elevator &&

    976                          !strcmp(e->elevator_name, CONFIG_DEFAULT_IOSCHED)))

    977                                 def = " (default)";

    978

    979         printk(KERN_INFO "io scheduler %s registered%s/n", e->elevator_name, def);

    980         return 0;

    981 }

看到list_add_tail那行了吗.那么这个elevator_type结构体又代表了什么呢?正如其名,它代表着一种电梯算法的类型,比如对于cfq,在cfq-iosched.c文件中,就定义了这么一个结构体变量iosched_cfq.

   2188 static struct elevator_type iosched_cfq = {

   2189         .ops = {

   2190                 .elevator_merge_fn =            cfq_merge,

   2191                 .elevator_merged_fn =           cfq_merged_request,

   2192                 .elevator_merge_req_fn =        cfq_merged_requests,

   2193                 .elevator_allow_merge_fn =      cfq_allow_merge,

   2194                 .elevator_dispatch_fn =         cfq_dispatch_requests,

   2195                 .elevator_add_req_fn =          cfq_insert_request,

   2196                 .elevator_activate_req_fn =     cfq_activate_request,

   2197                 .elevator_deactivate_req_fn =   cfq_deactivate_request,

   2198                 .elevator_queue_empty_fn =      cfq_queue_empty,

   2199                .elevator_completed_req_fn =    cfq_completed_request,

   2200                 .elevator_former_req_fn =       elv_rb_former_request,

   2201                 .elevator_latter_req_fn =       elv_rb_latter_request,

   2202                 .elevator_set_req_fn =          cfq_set_request,

   2203                 .elevator_put_req_fn =          cfq_put_request,

   2204                 .elevator_may_queue_fn =        cfq_may_queue,

   2205                 .elevator_init_fn =             cfq_init_queue,

   2206                 .elevator_exit_fn =             cfq_exit_queue,

   2207                 .trim =                         cfq_free_io_context,

   2208         },

   2209         .elevator_attrs =       cfq_attrs,

   2210         .elevator_name =        "cfq",

   2211         .elevator_owner =       THIS_MODULE,

   2212 };

同样,我们可以找到,对于noop,也有类似的变量.

     87 static struct elevator_type elevator_noop = {

     88         .ops = {

     89              .elevator_merge_req_fn          = noop_merged_requests,

     90                 .elevator_dispatch_fn           = noop_dispatch,

     91                 .elevator_add_req_fn            = noop_add_request,

     92                 .elevator_queue_empty_fn        = noop_queue_empty,

     93                 .elevator_former_req_fn         = noop_former_request,

     94                 .elevator_latter_req_fn         = noop_latter_request,

     95                 .elevator_init_fn               = noop_init_queue,

     96                 .elevator_exit_fn               = noop_exit_queue,

     97         },

     98         .elevator_name = "noop",

     99         .elevator_owner = THIS_MODULE,

    100 };

所以,我们就知道这个e到底是要得到什么了,如果你什么都没设置,那么它只能选择最差的那个,noop.于是到现在我们终于明白elv_register_queue()中那个e->elevator_type是啥了.而我们要的是e->elevator_type->elevator_attrs.对于cfq,很显然,它就是cfq_attrs.在block/cfq-iosched.c中:

   2175 static struct elv_fs_entry cfq_attrs[] = {

   2176         CFQ_ATTR(quantum),

   2177         CFQ_ATTR(fifo_expire_sync),

   2178         CFQ_ATTR(fifo_expire_async),

   2179         CFQ_ATTR(back_seek_max),

   2180         CFQ_ATTR(back_seek_penalty),

   2181         CFQ_ATTR(slice_sync),

   2182         CFQ_ATTR(slice_async),

   2183         CFQ_ATTR(slice_async_rq),

   2184         CFQ_ATTR(slice_idle),

   2185         __ATTR_NULL

   2186 };

所以,那个while循环的sysfs_create_file的功绩就是以上面这个数组的元素的名字建立一堆的文件.而这正是我们在/sys/block/sdf/queue/iosched/目录下面看到的那些文件.

至此,elv_register_queue就算是结束了,从而blk_register_queue()也就结束了,而add_disk这个不朽的函数终于大功告成.这一刻开始,整个块设备工作的大舞台就已经搭好了.对于sd那边来说,sd_probe就是在结束add_disk之后结束的.

看完之后,我深深的吸了一口气,我不得不承认,add_disk这个函数,这个只有四行代码的函数,很好,很强大.写代码毕竟不是写琼瑶剧本,不可能像<<一帘幽梦>>里的一句”我爱你”,需要用四十几集来诠释,那才叫一个深刻呢!