前兩篇我們編寫了在記憶體中的最簡單的塊裝置驅動程式，併為其更換了我們心儀的’noop‘IO排程器。本篇我們試著搞清楚核心的塊裝置層在這裡為我們做的事情，以及我們如何做點自己想做的事情。

其實，我們前面兩篇都是圍繞著請求佇列（request_queue）這東西做事情。初始化請求佇列時我們註冊上驅動處理請求（request）的策略函式（simp_blkdev_do_request），然後在gendisk結構初始化時又填充上前面初始化好的queue。後面我們又用‘noop’IO排程器更換掉預設的'cfq'排程器。

下面試著搞清楚通用塊層在這裡的框架機制。先看一張圖：

當通用塊層以上的層要對塊裝置進行訪問時，通常是準備好一個bio，呼叫generic_make_request(struct bio *bio)，OK。

但是我們是編寫底層驅動的可憐IT男，要是不知道generic_make_request是怎麼把我們前面實現的simp_blkdev_do_request和request_queue聯絡起來，那就相當沒有安全感。於是，我們開始RTFSC。

既然是圍著request_queue做文章，那麼我們先看下這個資料結構：

struct request_queue{

......

request_fn_proc *request_fn;// Method that implements the entry point of the strategy routine of the driver

make_request_fn *make_request_fn;//Method invoked when a new request has to be inserted in the queue

......

}

聰明的你肯定也看出來了，上面是兩個函式指標，它們的定義如下：

typedef void (request_fn_proc) (struct request_queue *q);
typedef int (make_request_fn) (struct request_queue *q, struct bio *bio);

對上面的資料結構留個印象，我們開始看 通用塊層的入口函式generic_make_request(struct bio *bio)。你可以發現下面的呼叫關係

generic_make_request(struct bio *bio)  ------>  __generic_make_request  ------> q->make_request_fn(q, bio)

於是我們得出結論，generic_make_request()最終是通過呼叫request_queue.make_request_fn函式完成bio所描述的請求處理的。

那麼，make_request_fn具體又指向哪個函式呢？我們前面也沒有實現過make_request_fn這樣的函式啊？！

我們只記得初始化request_queue時呼叫了blk_init_queue(request_fn_proc *, spinlock_t *)這個函式，所以我們來看一下這個函式，

blk_init_queue(request_fn_proc *rfn, spinlock_t *lock) ------> blk_init_queue_node() ------> 

q-> unplug_fn = generic_unplug_device; 

q->request_fn = rfn;

blk_queue_make_request(q, __make_reqeust) ------> q->make_request_fn = mfn(即__make_request)

原來，我們request_queue的make_request_fn實際上指向了__make_request()函式。這樣，大名鼎鼎的__make_request()函式就可以叫來某個IO排程器幫忙，並對bio做些利於使用者的加工，比如將其對映到非線性對映區域。至此，我們知道了一個新的request是如何被提交給IO排程器的了（通過__make_request）。我們也知道了我們編寫的simp_blkdev_do_request就是在這裡被賦值給q->request_fn的了(通過blk_queue_make_request)。那麼，通用塊層的框架是什麼時候對我們的simp_blkdev_do_request函式進行呼叫，從而真正執行對資料的拷貝了呢？

這裡有點複雜，先補充一點理論知識，就一點，塊裝置有“阻塞”和“非阻塞”的狀態，從而通用塊層才能利用這樣的機制推遲對請求的處理，從而給了IO排程參與的機會；當“非阻塞”時（該函式為blk_remove_plug），才能夠處理請求。

有了這樣的知識，我們RTFSC時見到blk_remove_plug就不奇怪了。好了，我們下面給出q->request_fn指向的simp_blkdev_do_request在何時被呼叫。

這次從__make_request()開始，這函式果然強大。。

__make_request() ------> add_request() ------> __elv_add_request() ------> elv_insert() ------> blk_remove_plug ------> blk_unplug_timeout ------> kblocked_schedule_work ------> blk_unplug_work() ------> q->unplug_fn()

如果你循到了上面的呼叫關係，那麼恭喜你，你遇到了新問題，q->unplug_fn是哪隻鳥，它呼叫的誰？？

如果你記性還不錯，那麼你會想起我們blk_init_queue呼叫關係裡面有一個“ q-> unplug_fn = generic_unplug_device; ”，很好，我們發現q->unplug_fn其實呼叫的是通用塊層另一個小有名氣的函式，generic_unplug_device()。我們繼續尋找呼叫關係。

generic_unplug_device() ------> __generic_unplug_device() ------> q->request_fn()

到這裡，長征結束，期間和IO排程器打個照面，見識了塊裝置解除阻塞狀態，還喚醒了核心的工作佇列，但最終我們可以大呼一口氣了。。。

綜上所述，當我們實現了塊裝置驅動程式的策略函式（例如前面實現的simp_blkdev_do_request）並用其作為引數初始化一個request_queue後，通用塊層的make_request_fn 函式指標幫我們指定了強力幫手 __make_request，該幫手又拉上了IO排程器，於是，一個bio經過通用塊層、IO排程層的處理，最後以request_queue中的request餵給我們實現的策略函式。