现在我们块设备也有了，队列也有了，要提交请求也就可以开始提交了。那就让我们回到generic_make_request来研究一下如何提交请求如何处理请求吧。我们看到，函数最后调用q->make_request_fn(q, bio)。对 make_request_fn 函数的调用可以认为是 IO调度层的入口，该函数用于向请求队列中添加请求。该函数是在创建请求队列时指定的，代码如下（blk_init_queue 函数中）：
q->request_fn = rfn;
blk_queue_make_request(q, __make_request);
前面看到函数 blk_queue_make_request 将函数 __make_request 的地址赋予了请求队列 q 的 make_request_fn 成员：
void blk_queue_make_request(struct request_queue *q, make_request_fn *mfn)
{
q->nr_requests = BLKDEV_MAX_RQ;
q->make_request_fn = mfn;
……
那么，__make_request函数才是IO调度层的真实入口，来自block/ll_rw_blk.c：
2846static int __make_request(request_queue_t *q, struct bio *bio)
2847{
2848 struct request *req;
2849 int el_ret, rw, nr_sectors, cur_nr_sectors, barrier, err, sync;
2850 unsigned short prio;
2851 sector_t sector;
2852
2853 sector = bio->bi_sector;
2854 nr_sectors = bio_sectors(bio);
2855 cur_nr_sectors = bio_cur_sectors(bio);
2856 prio = bio_prio(bio);
2857
2858 rw = bio_data_dir(bio);
2859 sync = bio_sync(bio);
2860
2861 /*
2862 * low level driver can indicate that it wants pages above a
2863 * certain limit bounced to low memory (ie for highmem, or even
2864 * ISA dma in theory)
2865 */
2866 blk_queue_bounce(q, &bio);
2867
2868 spin_lock_prefetch(q->queue_lock);
2869
2870 barrier = bio_barrier(bio);
2871 if (unlikely(barrier) && (q->next_ordered == QUEUE_ORDERED_NONE)) {
2872 err = -EOPNOTSUPP;
2873 goto end_io;
2874 }
2875
2876 spin_lock_irq(q->queue_lock);
2877
2878 if (unlikely(barrier) || elv_queue_empty(q))
2879 goto get_rq;
2880
2881 el_ret = elv_merge(q, &req, bio);
2882 switch (el_ret) {
2883 case ELEVATOR_BACK_MERGE:
2884 BUG_ON(!rq_mergeable(req));
2885
2886 if (!q->back_merge_fn(q, req, bio))
2887 break;
2888
2889 blk_add_trace_bio(q, bio, BLK_TA_BACKMERGE);
2890
2891 req->biotail->bi_next = bio;
2892 req->biotail = bio;
2893 req->nr_sectors = req->hard_nr_sectors += nr_sectors;
2894 req->ioprio = ioprio_best(req->ioprio, prio);
2895 drive_stat_acct(req, nr_sectors, 0);
2896 if (!attempt_back_merge(q, req))
2897 elv_merged_request(q, req);
2898 goto out;
2899
2900 case ELEVATOR_FRONT_MERGE:
2901 BUG_ON(!rq_mergeable(req));
2902
2903 if (!q->front_merge_fn(q, req, bio))
2904 break;
2905
2906 blk_add_trace_bio(q, bio, BLK_TA_FRONTMERGE);
2907
2908 bio->bi_next = req->bio;
2909 req->bio = bio;
2910
2911 /*
2912 * may not be valid. if the low level driver said
2913 * it didn't need a bounce buffer then it better
2914 * not touch req->buffer either...
2915 */
2916 req->buffer = bio_data(bio);
2917 req->current_nr_sectors = cur_nr_sectors;
2918 req->hard_cur_sectors = cur_nr_sectors;
2919 req->sector = req->hard_sector = sector;
2920 req->nr_sectors = req->hard_nr_sectors += nr_sectors;
2921 req->ioprio = ioprio_best(req->ioprio, prio);
2922 drive_stat_acct(req, nr_sectors, 0);
2923 if (!attempt_front_merge(q, req))
2924 elv_merged_request(q, req);
2925 goto out;
2926
2927 /* ELV_NO_MERGE: elevator says don't/can't merge. */
2928 default:
2929 ;
2930 }
2931
2932get_rq:
2933 /*
2934 * Grab a free request. This is might sleep but can not fail.
2935 * Returns with the queue unlocked.
2936 */
2937 req = get_request_wait(q, rw, bio);
2938
2939 /*
2940 * After dropping the lock and possibly sleeping here, our request
2941 * may now be mergeable after it had proven unmergeable (above).
2942 * We don't worry about that case for efficiency. It won't happen
2943 * often, and the elevators are able to handle it.
2944 */
2945 init_request_from_bio(req, bio);
2946
2947 spin_lock_irq(q->queue_lock);
2948 if (elv_queue_empty(q))
2949 blk_plug_device(q);
2950 add_request(q, req);
2951out:
2952 if (sync)
2953 __generic_unplug_device(q);
2954
2955 spin_unlock_irq(q->queue_lock);
2956 return 0;
2957
2958end_io:
2959 bio_endio(bio, nr_sectors << 9, err);
2960 return 0;
2961}
__make_request 函数比较复杂，它接收request_queue类型的描述符q和一个bio结构的描述符bio作为其参数，然后执行如下操作：
2853内部变量sector赋值为bio的bi_sector字段，即将传送的bio的第一个扇区。2854行通过bio_sectors(bio)宏得到需要传送多少个连续的扇区，并赋值给内部变量nr_sectors。bio_sectors宏来自include/linux/bio.h
#define bio_sectors(bio) ((bio)->bi_size >> 9)
bio->bi_size我们知道，在前面如果一个页中的4个块内容连续，则do_mpage_readpage通过调用bio_add_page将4个块的大小4096赋值给bio的bi_size字段，那么nr_sectors就是4096>>9，等于8，表示这个bio一共8个扇区待传输。
2866行，如果需要，调用blk_cqueue_bounce()函数建立一个回弹缓冲区。如果回弹缓冲区被建立，__make_request()函数将对该缓冲区而不是原先的bio结构进行操作。关于回弹缓冲区的相关知识，请查阅相关资料，这里我们不做过多的介绍。
2878行，调用I/O调度程序的elv_queue_empty()函数检查请求队列中是否存在待处理请求——注意，调度队列可能是空的，但是I/O调度程序的其他队列可能包含待处理请求。如果没有待处理请求，那么调用blk_plug_device()函数插入请求队列，然后跳转到2932行的get_rq标号处。
如果插入的请求队列包含待处理请求，则走到2881行调用I/O调度程序的elv_merge()函数检查新的bio结构是否可以并入已存在的请求中。
该函数将返回三个可能值：
1. ELEVATOR_NO_MERGE：已经存在的请求中不能包含bio结构；这种情况下，跳转到2932行的get_rq标号处。
2. ELEVATOR_BACK_MERGE：bio结构可作为末尾的bio而插入到某个请求req中；这种情形下，函数调用q->back_merge_fn方法检查是否可以扩展该请求。如果不行，则跳转到2932行的get_rq标号处。否则，将bio描述符插入req链表的末尾并更新req的相应字段值。然后，函数试图将该请求与其后面的请求合并（新的bio可能填充在两个请求之间）。
3. ELEVATOR_FRONT_MERGE：bio结构可作为某个请求req的第一个bio被插入；这种情形下，函数调用q->front_merge_fn方法检查是否可以扩展该请求。如果不行，则跳转到2932行的get_rq标号处。否则，将bio描述符插入req链表的首部并更新req的相应字段值。然后，试图将该请求与其前面的请求合并。
不管是ELEVATOR_BACK_MERGE还是ELEVATOR_FRONT_MERGE，说明bio已经被并入存在的请求中，跳转到2951行out标号处终止函数。
下面来看2932行的get_rq标号处，bio必须被插人到一个新的请求中。那么通过get_request_wait给我们这个分区的请求队列q分配一个新的请求描述符request。如果没有空闲的内存，get_request_wait函数将调用io_schedule挂起当前进程，直到设置了bio->bi_rw中的BIO_RW_AHEAD标志，该标志表明这个I/O操作是一次预读；在这种情形下，调用bio_endio()并终止：此时将不会执行数据传送。
然后调用2945行的init_request_from_bio(req, bio)初始化请求描述符中的字段。主要有：
a) 根据bio描述符的内容初始化各个字段，包括扇区数、当前bio以及当前段。
b) 设置flags字段中的REQ_CMD标志（说明这次request是一个标准的读或写操作）。
c) 如果第一个bio段的页框存放在低端内存，则将buffer字段设置为缓冲区的线性地址。
d) 将rc_disk字段设置为bio->bi_bdev->bd_disk的地址。
e) 将bio插入请求链表。
f) 将start_time字段设置为jiffies的值。
回到__make_request的2948-2949行，再次调用elv_queue_empty检查一下请求队列中是否存在待处理请求。如果没有待处理请求，那么调用blk_plug_device()函数插入请求队列。不管怎样，都会执行2950行的add_request函数：
static inline void add_request(request_queue_t * q, struct request * req)
{
drive_stat_acct(req, req->nr_sectors, 1);
if (q->activity_fn)
q->activity_fn(q->activity_data, rq_data_dir(req));
/*
* elevator indicated where it wants this request to be
* inserted at elevator_merge time
*/
__elv_add_request(q, req, ELEVATOR_INSERT_SORT, 0);
}
add_request函数本质上调用__elv_add_request函数通过电梯算法把这个新的request插入到对应requesr_queue合适的位置。在介绍__elv_add_request函数之前，我们先介绍几个宏，来自include/linux/elevator.h：
155 /*
156 * Insertion selection
157 */
158 #define ELEVATOR_INSERT_FRONT 1
159 #define ELEVATOR_INSERT_BACK 2
160 #define ELEVATOR_INSERT_SORT 3
161 #define ELEVATOR_INSERT_REQUEUE 4
很明显，在add_request函数中传递进来的是ELEVATOR_INSERT_SORT，表示从前面插入。那么带着这个where我们进入下一个函数，即__elv_add_request。来自block/elevator.c：
646 void __elv_add_request(request_queue_t *q, struct request *rq, int where,
647 int plug)
648 {
649 if (q->ordcolor)
650 rq->cmd_flags |= REQ_ORDERED_COLOR;
651
652 if (rq->cmd_flags & (REQ_SOFTBARRIER | REQ_HARDBARRIER)) {
653 /*
654 * toggle ordered color
655 */
656 if (blk_barrier_rq(rq))
657 q->ordcolor ^= 1;
658
659 /*
660 * barriers implicitly indicate back insertion
661 */
662 if (where == ELEVATOR_INSERT_SORT)
663 where = ELEVATOR_INSERT_BACK;
664
665 /*
666 * this request is scheduling boundary, update
667 * end_sector
668 */
669 if (blk_fs_request(rq)) {
670 q->end_sector = rq_end_sector(rq);
671 q->boundary_rq = rq;
672 }
673 } else if (!(rq->cmd_flags & REQ_ELVPRIV) && where == ELEVATOR_INSERT_SORT)
674 where = ELEVATOR_INSERT_BACK;
675
676 if (plug)
677 blk_plug_device(q);
678
679 elv_insert(q, rq, where);
680 }
传入的参数plug等于0，所以blk_plug_device()不会被执行。很明显，一路走来我们根本没有设置什么REQ_SOFTBARRIER、REQ_HARDBARRIER或REQ_ELVPRIV标识，所以前面都和我们无关，直接跳到最后一行这个elv_insert()：
548 void elv_insert(request_queue_t *q, struct request *rq, int where)
549 {
550 struct list_head *pos;
551 unsigned ordseq;
552 int unplug_it = 1;
553
554 blk_add_trace_rq(q, rq, BLK_TA_INSERT);
555
556 rq->q = q;
557
558 switch (where) {
559 case ELEVATOR_INSERT_FRONT:
560 rq->cmd_flags |= REQ_SOFTBARRIER;
561
562 list_add(&rq->queuelist, &q->queue_head);
563 break;
564
565 case ELEVATOR_INSERT_BACK:
566 rq->cmd_flags |= REQ_SOFTBARRIER;
567 elv_drain_elevator(q);
568 list_add_tail(&rq->queuelist, &q->queue_head);
569 /*
570 * We kick the queue here for the following reasons.
571 * - The elevator might have returned NULL previously
572 * to delay requests and returned them now. As the
573 * queue wasn't empty before this request, ll_rw_blk
574 * won't run the queue on return, resulting in hang.
575 * - Usually, back inserted requests won't be merged
576 * with anything. There's no point in delaying queue
577 * processing.
578 */
579 blk_remove_plug(q);
580 q->request_fn(q);
581 break;
582
583 case ELEVATOR_INSERT_SORT:
584 BUG_ON(!blk_fs_request(rq));
585 rq->cmd_flags |= REQ_SORTED;
586 q->nr_sorted++;
587 if (rq_mergeable(rq)) {
588 elv_rqhash_add(q, rq);
589 if (!q->last_merge)
590 q->last_merge = rq;
591 }
592
593 /*
594 * Some ioscheds (cfq) run q->request_fn directly, so
595 * rq cannot be accessed after calling
596 * elevator_add_req_fn.
597 */
598 q->elevator->ops->elevator_add_req_fn(q, rq);
599 break;
600
601 case ELEVATOR_INSERT_REQUEUE:
602 /*
603 * If ordered flush isn't in progress, we do front
604 * insertion; otherwise, requests should be requeued
605 * in ordseq order.
606 */
607 rq->cmd_flags |= REQ_SOFTBARRIER;
608
609 /*
610 * Most requeues happen because of a busy condition,
611 * don't force unplug of the queue for that case.
612 */
613 unplug_it = 0;
614
615 if (q->ordseq == 0) {
616 list_add(&rq->queuelist, &q->queue_head);
617 break;
618 }
619
620 ordseq = blk_ordered_req_seq(rq);
621
622 list_for_each(pos, &q->queue_head) {
623 struct request *pos_rq = list_entry_rq(pos);
624 if (ordseq <= blk_ordered_req_seq(pos_rq))
625 break;
626 }
627
628 list_add_tail(&rq->queuelist, pos);
629 break;
630
631 default:
632 printk(KERN_ERR "%s: bad insertion point %d/n",
633 __FUNCTION__, where);
634 BUG();
635 }
636
637 if (unplug_it && blk_queue_plugged(q)) {
638 int nrq = q->rq.count[READ] + q->rq.count[WRITE]
639 - q->in_flight;
640
641 if (nrq >= q->unplug_thresh)
642 __generic_unplug_device(q);
643 }
644 }
由于我们是从前面插，所以我们执行562行这个list_add，struct request有一个成员struct list_head queuelist，而struct request_queue有一个成员struct list_head queue_head，所以我们就把前者插入到后者所代表的这个队伍中来。然后咱们就返回了。
以上所有操作全部完成后，在终止之前，2952行检查是否设置了bio->bi_rw中的BIO_RW_SYNC标志。如果是，则对“请求队列”调用generic_unplug_device()函数以卸载设备驱动程序，并直接调用q->request_fn(q)，这个函数是什么，马上会看到。
如果在调用__make_request()函数之前请求队列不是空的，那么说明该请求队列要么已经被拔掉过，要么很快将被拔掉——因为每个拥有待处理请求的插入请求队列q都有一个正在运行的动态定时器q->unplug_timer。另一方面，如果请求队列是空的，则__make_request()函数插入请求队列。或迟（最坏的情况是当拔出的定时器到期了）或最早（从__make_request()中退出时，如果设置了bio的BIO_RW_SYNC标志），该请求队列都会被拔掉。任何情形下，块设备驱动程序的策略例程最后都将处理调度队列中的请求。
当generic_make_request执行完scsi磁盘设备对应请求队列的q->make_request_fn方法，也就是刚才分析的__make_request以后，块设备的调度层就结束了。至于包含该bio的request放入到请求队列中后，何时被处理就由 IO 调度器的调度算法决定了。一旦该请求能够被处理，便调用请求队列中request_fn 字段所指向的函数处理。这个成员的初始化也是在创建请求队列时设置的：
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 }
我们看到，给scsi设备创建request_queue的时候，是把scsi_request_fn作为他的request_fn 字段所指向的函数地址，所以这个scsi_request_fn就是scsi底层驱动的入口。
