在學(xué)習(xí)塊設(shè)備原理的時候，我最關(guān)系塊設(shè)備的數(shù)據(jù)流程，從應(yīng)用程序調(diào)用Read或者Write開始，數(shù)據(jù)在內(nèi)核中到底是如何流通、處理的呢？然后又如何抵達(dá)具體的物理設(shè)備的呢？下面對一個帶Cache功能的塊設(shè)備數(shù)據(jù)流程進(jìn)行分析。一起去看看吧！
1、 用戶態(tài)程序通過open()打開指定的塊設(shè)備，通過systemcall機(jī)制陷入內(nèi)核，執(zhí)行blkdev_open()函數(shù)，該函數(shù)注冊到文件系統(tǒng)方法（file_operations）中的open上。在blkdev_open函數(shù)中調(diào)用bd_acquire()函數(shù)，bd_acquire函數(shù)完成文件系統(tǒng)inode到塊設(shè)備bdev的轉(zhuǎn)換，具體的轉(zhuǎn)換方法通過hash查找實現(xiàn)。得到具體塊設(shè)備的bdev之后，調(diào)用do_open()函數(shù)完成設(shè)備打開的操作。在do_open函數(shù)中會調(diào)用到塊設(shè)備驅(qū)動注冊的open方法，具體調(diào)用如下：gendisk->fops->open(bdev->bd_inode, file)。
2、 用戶程序通過read、write函數(shù)對設(shè)備進(jìn)行讀寫，文件系統(tǒng)會調(diào)用相應(yīng)的方法，通常會調(diào)用如下兩個函數(shù)：generic_file_read和blkdev_file_write。在讀寫過程中采用了多種策略，首先分析讀過程。
3、 用戶態(tài)調(diào)用了read函數(shù)，內(nèi)核執(zhí)行g(shù)eneric_file_read，如果不是direct io方式，那么直接調(diào)用do_generic_file_read->do_generic_mapping_read()函數(shù)，在do_generic_mapping_read（函數(shù)位于filemap.c）函數(shù)中，首先查找數(shù)據(jù)是否命中Cache，如果命中，那么直接將數(shù)據(jù)返回給用戶態(tài)；否則通過address_space->a_ops->readpage函數(shù)發(fā)起一個真實的讀請求。在readpage函數(shù)中，構(gòu)造一個buffer_head，設(shè)置bh回調(diào)函數(shù)end_buffer_async_read，然后調(diào)用submit_bh發(fā)起請求。在submit_bh函數(shù)中，根據(jù)buffer_head構(gòu)造bio，設(shè)置bio的回調(diào)函數(shù)end_bio_bh_io_sync，最后通過submit_bio將bio請求發(fā)送給指定的快設(shè)備。
4、 如果用戶態(tài)調(diào)用了一個write函數(shù)，內(nèi)核執(zhí)行blkdev_file_write函數(shù)，如果不是direct io操作方式，那么執(zhí)行buffered write操作過程，直接調(diào)用generic_file_buffered_write函數(shù)。Buffered write操作方法會將數(shù)據(jù)直接寫入Cache，并進(jìn)行Cache的替換操作，在替換操作過程中需要對實際的快設(shè)備進(jìn)行操作，address_space->a_ops提供了塊設(shè)備操作的方法。當(dāng)數(shù)據(jù)被寫入到Cache之后，write函數(shù)就可以返回了，后繼異步寫入的任務(wù)絕大部分交給了pdflush daemon（有一部分在替換的時候做了）
5、 數(shù)據(jù)流操作到這一步，我們已經(jīng)很清楚用戶的數(shù)據(jù)是如何到內(nèi)核了。與用戶最接近的方法是file_operations，每種設(shè)備類型都定義了這一方法（由于Linux將所有設(shè)備都看成是文件，所以為每類設(shè)備都定義了文件操作方法，例如，字符設(shè)備的操作方法為def_chr_fops，塊設(shè)備為def_blk_fops，網(wǎng)絡(luò)設(shè)備為bad_sock_fops）。每種設(shè)備類型底層操作方法是不一樣的，但是通過file_operations方法將設(shè)備類型的差異化屏蔽了，這就是Linux能夠?qū)⑺性O(shè)備都理解為文件的緣由。到這里，又提出一個問題：既然這樣，那設(shè)備的差異化又該如何體現(xiàn)呢？在文件系統(tǒng)層定義了文件系統(tǒng)訪問設(shè)備的方法，該方法就是address_space_operations，文件系統(tǒng)通過該方法可以訪問具體的設(shè)備。對于字符設(shè)備而言，沒有實現(xiàn)address_space_operations方法，也沒有必要，因為字符設(shè)備的接口與文件系統(tǒng)的接口是一樣的，在字符設(shè)備open操作的過程中，將inode所指向的file_operations替換成cdev所指向的file_operations就可以了。這樣用戶層讀寫字符設(shè)備可以直接調(diào)用cdev中file_operations方法了。
6、 截至到步驟（4），讀操作在沒有命中Cache的情況下通過address_space_operations方法中的readpage函數(shù)發(fā)起塊設(shè)備讀請求；寫操作在替換Cache或者Pdflush喚醒時發(fā)起塊設(shè)備請求。發(fā)起塊設(shè)備請求的過程都一樣，首先根據(jù)需求構(gòu)建bio結(jié)構(gòu)，bio結(jié)構(gòu)中包含了讀寫地址、長度、目的設(shè)備、回調(diào)函數(shù)等信息。構(gòu)造完bio之后，通過簡單的submit_bio函數(shù)將請求轉(zhuǎn)發(fā)給具體的塊設(shè)備。從這里可以看出，塊設(shè)備接口很簡單，接口方法為submit_bio（更底層函數(shù)為generic_make_request），數(shù)據(jù)結(jié)構(gòu)為struct bio。
7、 submit_bio函數(shù)通過generic_make_request轉(zhuǎn)發(fā)bio，generic_make_request是一個循環(huán)，其通過每個塊設(shè)備下注冊的q->make_request_fn函數(shù)與塊設(shè)備進(jìn)行交互。如果訪問的塊設(shè)備是一個有queue的設(shè)備，那么會將系統(tǒng)的__make_request函數(shù)注冊到q->make_request_fn中；否則塊設(shè)備會注冊一個私有的方法。在私有的方法中，由于不存在queue隊列，所以不會處理具體的請求，而是通過修改bio中的方法實現(xiàn)bio的轉(zhuǎn)發(fā)，在私有make_request方法中，往往會返回1，告訴generic_make_request繼續(xù)轉(zhuǎn)發(fā)比bio。Generic_make_request的執(zhí)行上下文可能有兩種，一種是用戶上下文，另一種為pdflush所在的內(nèi)核線程上下文。
8、 通過generic_make_request的不斷轉(zhuǎn)發(fā)，最后請求一定會到一個存在queue隊列的塊設(shè)備上，假設(shè)最終的那個塊設(shè)備是某個scsi disk（/dev/sda）。generic_make_request將請求轉(zhuǎn)發(fā)給sda時，調(diào)用__make_request，該函數(shù)是Linux提供的塊設(shè)備請求處理函數(shù)。在該函數(shù)中實現(xiàn)了極其重要的操作，通常所說的IO Schedule就在該函數(shù)中實現(xiàn)。在該函數(shù)中試圖將轉(zhuǎn)發(fā)過來的bio merge到一個已經(jīng)存在的request中，如果可以合并，那么將新的bio請求掛載到一個已經(jīng)存在request中。如果不能合并，那么分配一個新的request，然后將bio添加到其中。這一切搞定之后，說明通過generic_make_request轉(zhuǎn)發(fā)的bio已經(jīng)抵達(dá)了內(nèi)核的一個站點——request，找到了一個臨時歸宿。此時，還沒有真正啟動物理設(shè)備的操作。在__make_request退出之前，會判斷一個bio中的sync標(biāo)記，如果該標(biāo)記有效，說明請求的bio是一個是實時性很強(qiáng)的操作，不能在內(nèi)核中停留，因此調(diào)用了__generic_unplug_device函數(shù)，該函數(shù)將觸發(fā)下一階段的操作；如果該標(biāo)記無效的話，那么該請求就需要在queue隊列中停留一段時間，等到queue隊列觸發(fā)鬧鐘響了之后，再觸發(fā)下一階段的操作。__make_request函數(shù)返回0，告訴generic_make_request無需再轉(zhuǎn)發(fā)bio了，bio轉(zhuǎn)發(fā)結(jié)束。
9、 到目前為止，文件系統(tǒng)（pdflush或者address_space_operations）發(fā)下來的bio已經(jīng)merge到request queue中，如果為sync bio，那么直接調(diào)用__generic_unplug_device，否則需要在unplug timer的軟中斷上下文中執(zhí)行q->unplug_fn。后繼request的處理方法應(yīng)該和具體的物理設(shè)備相關(guān)，但是在標(biāo)準(zhǔn)的塊設(shè)備上如何體現(xiàn)不同物理設(shè)備的差異性呢？這種差異性就體現(xiàn)在queue隊列的方法上，不同的物理設(shè)備，queue隊列的方法是不一樣的。舉例中的sda是一個scsi設(shè)備，在scsi middle level將scsi_request_fn函數(shù)注冊到了queue隊列的request_fn方法上。在q->unplug_fn（具體方法為：generic_unplug_device）函數(shù)中會調(diào)用request隊列的具體處理函數(shù)q->request_fn。Ok，到這一步實際上已經(jīng)將塊設(shè)備層與scsi總線驅(qū)動層聯(lián)系在了一起，他們的接口方法為request_fn（具體函數(shù)為scsi_request_fn）。
10、明白了第（9）點之后，接下來的過程實際上和具體的scsi總線操作相關(guān)了。在scsi_request_fn函數(shù)中會掃描request隊列，通過elv_next_request函數(shù)從隊列中獲取一個request。在elv_next_request函數(shù)中通過scsi總線層注冊的q->prep_rq_fn（scsi層注冊為scsi_prep_fn）函數(shù)將具體的request轉(zhuǎn)換成scsi驅(qū)動所能認(rèn)識的scsi command。獲取一個request之后，scsi_request_fn函數(shù)直接調(diào)用scsi_dispatch_cmd函數(shù)將scsi command發(fā)送給一個具體的scsi host。到這一步，有一個問題：scsi command具體轉(zhuǎn)發(fā)給那個scsi host呢？秘密就在于q->queuedata中，在為sda設(shè)備分配queue隊列時，已經(jīng)指定了sda塊設(shè)備與底層的scsi設(shè)備（scsi device）之間的關(guān)系，他們的關(guān)系是通過request queue維護(hù)的。
11、 在scsi_dispatch_cmd函數(shù)中，通過scsi host的接口方法queuecommand將scsi command發(fā)送給scsi host。通常scsi host的queuecommand方法會將接收到的scsi command掛到自己維護(hù)的隊列中，然后再啟動DMA過程將scsi command中的數(shù)據(jù)發(fā)送給具體的磁盤。DMA完畢之后，DMA控制器中斷CPU，告訴CPU DMA過程結(jié)束，并且在中斷上下文中設(shè)置DMA結(jié)束的中斷下半部。DMA中斷服務(wù)程序返回之后觸發(fā)軟中斷，執(zhí)行SCSI中斷下半部。
12、 在SCSi中斷下半部中，調(diào)用scsi command結(jié)束的回調(diào)函數(shù)，這個函數(shù)往往為scsi_done，在scsi_done函數(shù)調(diào)用blk_complete_request函數(shù)結(jié)束請求request，每個請求維護(hù)了一個bio鏈，所以在結(jié)束請求過程中回調(diào)每個請求中的bio回調(diào)函數(shù)，結(jié)束具體的bio。Bio又有文件系統(tǒng)的buffer head生成，所以在結(jié)束bio時，回調(diào)buffer_head的回調(diào)處理函數(shù)bio->bi_end_io（注冊為end_bio_bh_io_sync）。自此，由中斷引發(fā)的一系列回調(diào)過程結(jié)束，總結(jié)一下回調(diào)過程如下：scsi_done->end_request->end_bio->end_bufferhead。
13、 回調(diào)結(jié)束之后，文件系統(tǒng)引發(fā)的讀寫操作過程結(jié)束。
