華為的鴻蒙系統(tǒng)開源之后第一個(gè)想看的模塊就是 FS 模塊，想了解一下它的 IO 路徑與 linux 的區(qū)別?，F(xiàn)在鴻蒙開源的倉庫中有兩個(gè)內(nèi)核系統(tǒng)，一個(gè)是 liteos_a 系統(tǒng)，一個(gè)是 liteos_m 系統(tǒng)。兩者的區(qū)別主要是適應(yīng)的場景不一樣，liteos_a 系統(tǒng)適用于硬件資源更加豐富的場景，比如 CPU 更強(qiáng)，內(nèi)存更大；而 liteos_m 系統(tǒng)則適用于 IoT 設(shè)備，相對(duì)來說硬件資源比較弱一些。所以我們就拿 liteos_a 系統(tǒng)來分析一下它的 IO 棧吧，畢竟它應(yīng)對(duì)的場景更加復(fù)雜一些。

鴻蒙系統(tǒng) liteos_a Kernel 的下載地址在這：https://gitee.com/openharmony/kernel_liteos_a。

1.FS 源碼結(jié)構(gòu)

下載內(nèi)核源碼后發(fā)現(xiàn) fs 目錄下似乎缺少很多東西。

當(dāng)時(shí)覺得好奇怪，啥都沒有，那它的 shell 相關(guān)命令是怎么使用 fs 模塊進(jìn)行讀寫的呢？于是發(fā)現(xiàn)鴻蒙的 FS 模塊主要是從 Nuttx （注：Nuttx 是 Apache 正在孵化的實(shí)時(shí)操作系統(tǒng)內(nèi)核）那里借用了 FS 的相關(guān)實(shí)現(xiàn)。這是從內(nèi)核的 fs.h 引用的路徑發(fā)現(xiàn)的，它引用的路徑內(nèi)容如下：

../../../../../third_party/NuttX/include/nuttx/fs/fs.h

所以我們需要找到這個(gè)模塊，在 gitee 的倉庫中搜索 Nuttx 發(fā)現(xiàn)的確有這個(gè)倉庫，所以我們需要聯(lián)合兩個(gè)倉庫的代碼一起解讀 IO 棧的源碼。Nuttx 的倉庫地址為：https://gitee.com/openharmony/third_party_NuttX。

我們來看一下 Nuttx 的目錄結(jié)構(gòu)：

可以發(fā)現(xiàn) FS 的具體實(shí)現(xiàn)都在這個(gè) Nuttx 倉庫內(nèi)。接下來我們來看看鴻蒙系統(tǒng)的 IO 棧吧，因?yàn)?IO 棧的路徑比較多，所以我們選取塊設(shè)備（block device）的路徑來分析。

2. IO 整體架構(gòu)

鴻蒙系統(tǒng)關(guān)于塊設(shè)備的 IO 棧路徑整體架構(gòu)如下圖所示：

整體 IO 流程如下：

上層應(yīng)用會(huì)在用戶態(tài)下調(diào)用 read / write 接口，這會(huì)觸發(fā)系統(tǒng)調(diào)用（syscall）進(jìn)入內(nèi)核態(tài)；

系統(tǒng)調(diào)用往下調(diào)用 VFS 的接口，如 read 則對(duì)應(yīng) read，write 對(duì)應(yīng) write；

VFS 這層會(huì)根據(jù) fd 對(duì)應(yīng)的 file 結(jié)構(gòu)拿出超級(jí)塊的 inode，利用這個(gè) inode 繼續(xù)往下調(diào)用具體 driver 的 read / write 接口；

在塊設(shè)備的場景下，它是利用字符設(shè)備的驅(qū)動(dòng)作為它的代理，也就是 driver 下面的 bch。鴻蒙系統(tǒng)的設(shè)備驅(qū)動(dòng)中并沒有塊設(shè)備的驅(qū)動(dòng)，所以它做了一層 block_proxy，無論是字符設(shè)備還是塊設(shè)備的 IO 都會(huì)經(jīng)過 bch 驅(qū)動(dòng)。數(shù)據(jù)所位于的扇區(qū)以及偏移量（offset）計(jì)算位于這層；

IO 往下走會(huì)有一層緩存，叫 bcache。bcache 采用紅黑樹管理這些緩存的數(shù)據(jù)；

IO 再往下走就是塊設(shè)備的驅(qū)動(dòng)，內(nèi)核沒有通用的塊設(shè)備驅(qū)動(dòng)實(shí)現(xiàn)，它應(yīng)該是由不同的廠商來實(shí)現(xiàn)的。

3.鴻蒙 IO 流程源碼解讀

讀寫流程大致一樣，我們就看一下鴻蒙的讀數(shù)據(jù)流程吧。由于函數(shù)的源碼比較長，全貼出來也不太好，所以太長的源碼我只將關(guān)鍵的部分截出。

3.1 上層應(yīng)用讀取數(shù)據(jù)

上層應(yīng)用調(diào)用 read 接口，這個(gè)是系統(tǒng)的 POSIX 接口，read 接口原型如下：

#include 
ssize_t read(int fd, void *buf, size_t count); 

3.2 VFS

上層應(yīng)用在用戶態(tài)調(diào)用 read 接口后會(huì)觸發(fā)系統(tǒng)調(diào)用，這個(gè)系統(tǒng)調(diào)用在 Kernel 的如下文件中進(jìn)行注冊(cè)：

syscall/fs_syscall.c

對(duì)應(yīng)的系統(tǒng)調(diào)用函數(shù)為

237 行的 read 調(diào)用的是 VFS 這層的 read，VFS 這層的 read 函數(shù)實(shí)現(xiàn)位于 Nuttx 項(xiàng)目的如下路徑：

fs/vfs/fs_read.c

read函數(shù)從 fd （文件描述符）中獲取對(duì)應(yīng)的 file 對(duì)象指針，然后在調(diào)用 file_read 接口。file_read 也和 read 函數(shù)位于同一個(gè)文件下。它從 file 對(duì)象中獲取了超級(jí)塊的 inode 對(duì)象，然后使用這個(gè) inode 調(diào)用 bch 驅(qū)動(dòng)的 read 函數(shù)。

3.3 bch 驅(qū)動(dòng)

bch 驅(qū)動(dòng)是一個(gè)字符設(shè)備驅(qū)動(dòng)，它被用來當(dāng)做上層與塊設(shè)備驅(qū)動(dòng)的中間層。注冊(cè)塊設(shè)備驅(qū)動(dòng)時(shí)會(huì)調(diào)用 block_proxy 來做代理轉(zhuǎn)換，它的實(shí)現(xiàn)位于：

fs/driver/fs_blockproxy.c

當(dāng)打開（open）一個(gè)塊設(shè)備時(shí)，內(nèi)核會(huì)判斷 inode 是否是塊設(shè)備類型，如果是則調(diào)用 block_proxy 來做轉(zhuǎn)換處理。 當(dāng)上層調(diào)用 u.i_ops->read 時(shí)，它對(duì)應(yīng)的是 bch_read，它的實(shí)現(xiàn)位于：

drivers/bch/bchdev_driver.c

bch_read 會(huì)接著調(diào)用 bchlib_read，這個(gè)函數(shù)的實(shí)現(xiàn)位于：

drivers/bch/bchlib_read.c

它會(huì)根據(jù)偏移（offset）計(jì)算出在哪個(gè)扇區(qū)進(jìn)行讀數(shù)據(jù)，如果要讀取的數(shù)據(jù)只是某個(gè)扇區(qū)的一部分，則它會(huì)先利用 bchlib_readsector 將這個(gè)扇區(qū)全部讀出來，然后再把對(duì)應(yīng)的那部分?jǐn)?shù)據(jù)拷貝到內(nèi)存并返回。 bchlib_readsector 的實(shí)現(xiàn)位于如下位置：

drivers/bch/bchlib_cache.c

它會(huì)先將位于內(nèi)存的臟數(shù)據(jù)下刷，等臟數(shù)據(jù)都下刷完成后才會(huì)利用 los_disk_read 把數(shù)據(jù)從磁盤上讀上來。 los_disk_read 的實(shí)現(xiàn)位于 kernel 的如下位置：

fs/vfs/disk/disk.c

這 los_disk_read 這層會(huì)有一層緩存，叫 bcache。它會(huì)把每次 IO 的扇區(qū)緩存到內(nèi)存中，緩存的組織方式為紅黑樹。它是有大小限制的，不是無限增長，具體大小與內(nèi)存大小有關(guān)。 los_disk_read 在讀數(shù)據(jù)之前會(huì)先從 bcache 緩存中查找有沒有對(duì)應(yīng)的緩存扇區(qū)，如果有則直接將這個(gè)扇區(qū)返回，如果沒有則調(diào)用真正塊設(shè)備的 read 函數(shù)。這個(gè) read 函數(shù)在內(nèi)核中沒有對(duì)應(yīng)的實(shí)現(xiàn)，所以它是跟隨每個(gè)塊設(shè)備的驅(qū)動(dòng)的不同而不同。

整個(gè)讀數(shù)據(jù)流程源碼分析就到這里。

鴻蒙系統(tǒng)的 IO 棧分支比較多，這次的源碼解讀選用了塊設(shè)備的分支進(jìn)行分析，希望可以幫助大家更好的理解鴻蒙系統(tǒng)。最后我還想做一下鴻蒙系統(tǒng)與 Linux 關(guān)于 IO 棧的對(duì)比。

4.鴻蒙 IO 棧與 Linux IO 棧的對(duì)比

如果有研究過 linux IO 棧的同學(xué)應(yīng)該能體會(huì)到鴻蒙的 IO 棧是比較簡單。先來看一下 Linux 的 IO 棧整體架構(gòu)圖：

所以，我們對(duì)比一下鴻蒙系統(tǒng)和 Linux IO 棧的主要區(qū)別吧：

鴻蒙沒有 pagecache。所以鴻蒙的系統(tǒng)調(diào)用加不加 O_SYNC 應(yīng)該是一樣的，都是直接下到磁盤。

鴻蒙沒有通用塊層和 IO 調(diào)度層。在 Linux 中通用塊層是用來將連續(xù)的塊請(qǐng)求組成一個(gè) bio 結(jié)構(gòu)體，便于對(duì)接下層的調(diào)度管理。調(diào)度層的目的則是用來減少 IO 尋址時(shí)間，在這層也有多種調(diào)度算法可以選擇，如 cfq/deadline/noop 等。我覺得鴻蒙不是沒有這兩層，而是還沒有做，目前只是 IoT 的適用場景。等明年適用于手機(jī)的時(shí)候再看看，我覺得應(yīng)該也會(huì)做相關(guān)的處理，只不過不一定與 Linux 的處理一樣。

鴻蒙的驅(qū)動(dòng)層次不夠完整，需要用字符設(shè)備的驅(qū)動(dòng)來代理塊設(shè)備的驅(qū)動(dòng)，不知道這是基于什么考慮。

鴻蒙 bcache 的作用與 linux 的 pagecache 作用基本一致，只不過它們?cè)?IO 棧上所在的位置不一樣。
編輯：hfy