华为鸿蒙系统源码_鸿蒙系统 IO 栈分析 | 解读鸿蒙源码

华为的鸿蒙系统开源之后第一个想看的模块就是 FS 模块,想了解一下它的 IO 路径与 linux 的区别。现在鸿蒙开源的仓库中有两个内核系统,一个是 liteos_a 系统,一个是 liteos_m 系统。两者的区别主要是适应的场景不一样,liteos_a 系统适用于硬件资源更加丰富的场景,比如 CPU 更强,内存更大;而 liteos_m 系统则适用于 IoT 设备,相对来说硬件资源比较弱一些。所以我们就拿 liteos_a 系统来分析一下它的 IO 栈吧,毕竟它应对的场景更加复杂一些。

鸿蒙系统 liteos_a Kernel 的下载地址在这:https://gitee.com/openharmony/kernel_liteos_a。

1.FS 源码结构

下载内核源码后发现 fs 目录下似乎缺少很多东西。

华为鸿蒙系统源码_鸿蒙系统 IO 栈分析 | 解读鸿蒙源码_第1张图片

当时觉得好奇怪,啥都没有,那它的 shell 相关命令是怎么使用 fs 模块进行读写的呢?于是发现鸿蒙的 FS 模块主要是从 Nuttx (注:Nuttx 是 Apache 正在孵化的实时操作系统内核)那里借用了 FS 的相关实现。这是从内核的 fs.h 引用的路径发现的,它引用的路径内容如下:

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

所以我们需要找到这个模块,在 gitee 的仓库中搜索 Nuttx 发现的确有这个仓库,所以我们需要联合两个仓库的代码一起解读 IO 栈的源码。Nuttx 的仓库地址为:https://gitee.com/openharmony/third_party_NuttX。

我们来看一下 Nuttx 的目录结构:

华为鸿蒙系统源码_鸿蒙系统 IO 栈分析 | 解读鸿蒙源码_第2张图片

可以发现 FS 的具体实现都在这个 Nuttx 仓库内。接下来我们来看看鸿蒙系统的 IO 栈吧,因为 IO 栈的路径比较多,所以我们选取块设备(block device)的路径来分析。

2. IO 整体架构

鸿蒙系统关于块设备的 IO 栈路径整体架构如下图所示: 

华为鸿蒙系统源码_鸿蒙系统 IO 栈分析 | 解读鸿蒙源码_第3张图片

整体 IO 流程如下:

  1. 上层应用会在用户态下调用 read / write 接口,这会触发系统调用(syscall)进入内核态;

  2. 系统调用往下调用 VFS 的接口,如 read 则对应 read,write 对应 write;

  3. VFS 这层会根据 fd 对应的 file 结构拿出超级块的 inode,利用这个 inode 继续往下调用具体 driver 的 read / write 接口;

  4. 在块设备的场景下,它是利用字符设备的驱动作为它的代理,也就是 driver 下面的 bch。鸿蒙系统的设备驱动中并没有块设备的驱动,所以它做了一层 block_proxy,无论是字符设备还是块设备的 IO 都会经过 bch 驱动。数据所位于的扇区以及偏移量(offset)计算位于这层;

  5. IO 往下走会有一层缓存,叫 bcache。bcache 采用红黑树管理这些缓存的数据;

  6. IO 再往下走就是块设备的驱动,内核没有通用的块设备驱动实现,它应该是由不同的厂商来实现的。

3.鸿蒙 IO 流程源码解读

读写流程大致一样,我们就看一下鸿蒙的读数据流程吧。由于函数的源码比较长,全贴出来也不太好,所以太长的源码我只将关键的部分截出。

3.1 上层应用读取数据

上层应用调用 read 接口,这个是系统的 POSIX 接口,read 接口原型如下:

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

3.2 VFS

上层应用在用户态调用 read 接口后会触发系统调用,这个系统调用在 Kernel 的如下文件中进行注册:

syscall/fs_syscall.c

对应的系统调用函数为 

华为鸿蒙系统源码_鸿蒙系统 IO 栈分析 | 解读鸿蒙源码_第4张图片

237 行的 read 调用的是 VFS 这层的 read,VFS 这层的 read 函数实现位于 Nuttx 项目的如下路径:

fs/vfs/fs_read.c

华为鸿蒙系统源码_鸿蒙系统 IO 栈分析 | 解读鸿蒙源码_第5张图片

read函数从 fd (文件描述符)中获取对应的 file 对象指针,然后在调用 file_read 接口。file_read 也和 read 函数位于同一个文件下。它从 file 对象中获取了超级块的 inode 对象,然后使用这个 inode 调用 bch 驱动的 read 函数。

华为鸿蒙系统源码_鸿蒙系统 IO 栈分析 | 解读鸿蒙源码_第6张图片

3.3 bch 驱动

bch 驱动是一个字符设备驱动,它被用来当做上层与块设备驱动的中间层。注册块设备驱动时会调用 block_proxy 来做代理转换,它的实现位于:

fs/driver/fs_blockproxy.c

华为鸿蒙系统源码_鸿蒙系统 IO 栈分析 | 解读鸿蒙源码_第7张图片

当打开(open)一个块设备时,内核会判断 inode 是否是块设备类型,如果是则调用 block_proxy 来做转换处理。当上层调用 u.i_ops->read 时,它对应的是 bch_read,它的实现位于:

drivers/bch/bchdev_driver.c

华为鸿蒙系统源码_鸿蒙系统 IO 栈分析 | 解读鸿蒙源码_第8张图片

bch_read 会接着调用 bchlib_read,这个函数的实现位于:

drivers/bch/bchlib_read.c

华为鸿蒙系统源码_鸿蒙系统 IO 栈分析 | 解读鸿蒙源码_第9张图片

它会根据偏移(offset)计算出在哪个扇区进行读数据,如果要读取的数据只是某个扇区的一部分,则它会先利用 bchlib_readsector 将这个扇区全部读出来,然后再把对应的那部分数据拷贝到内存并返回。bchlib_readsector 的实现位于如下位置:

drivers/bch/bchlib_cache.c

华为鸿蒙系统源码_鸿蒙系统 IO 栈分析 | 解读鸿蒙源码_第10张图片

它会先将位于内存的脏数据下刷,等脏数据都下刷完成后才会利用 los_disk_read 把数据从磁盘上读上来。los_disk_read 的实现位于 kernel 的如下位置:

fs/vfs/disk/disk.c

华为鸿蒙系统源码_鸿蒙系统 IO 栈分析 | 解读鸿蒙源码_第11张图片

这 los_disk_read 这层会有一层缓存,叫 bcache。它会把每次 IO 的扇区缓存到内存中,缓存的组织方式为红黑树。它是有大小限制的,不是无限增长,具体大小与内存大小有关。los_disk_read 在读数据之前会先从 bcache 缓存中查找有没有对应的缓存扇区,如果有则直接将这个扇区返回,如果没有则调用真正块设备的 read 函数。这个 read 函数在内核中没有对应的实现,所以它是跟随每个块设备的驱动的不同而不同。

整个读数据流程源码分析就到这里。

鸿蒙系统的 IO 栈分支比较多,这次的源码解读选用了块设备的分支进行分析,希望可以帮助大家更好的理解鸿蒙系统。最后我还想做一下鸿蒙系统与 Linux 关于 IO 栈的对比。

4.鸿蒙 IO 栈与 Linux IO 栈的对比

如果有研究过 linux IO 栈的同学应该能体会到鸿蒙的 IO 栈是比较简单。先来看一下 Linux 的 IO 栈整体架构图:

华为鸿蒙系统源码_鸿蒙系统 IO 栈分析 | 解读鸿蒙源码_第12张图片

所以,我们对比一下鸿蒙系统和 Linux IO 栈的主要区别吧:

  1. 鸿蒙没有 pagecache。所以鸿蒙的系统调用加不加 O_SYNC 应该是一样的,都是直接下到磁盘。

  2. 鸿蒙没有通用块层和 IO 调度层。在 Linux 中通用块层是用来将连续的块请求组成一个 bio 结构体,便于对接下层的调度管理。调度层的目的则是用来减少 IO 寻址时间,在这层也有多种调度算法可以选择,如 cfq/deadline/noop 等。我觉得鸿蒙不是没有这两层,而是还没有做,目前只是 IoT 的适用场景。等明年适用于手机的时候再看看,我觉得应该也会做相关的处理,只不过不一定与 Linux 的处理一样。

  3. 鸿蒙的驱动层次不够完整,需要用字符设备的驱动来代理块设备的驱动,不知道这是基于什么考虑。

  4. 鸿蒙 bcache 的作用与 linux 的 pagecache 作用基本一致,只不过它们在 IO 栈上所在的位置不一样。

原文作者:GongMingWei 原文出处: https://my.oschina.net/u/4658560/blog/4612984

THE END

47326bf2df586f37d2ff2f9c8a6a917a.png

往期推荐

  • DevOps研发模式下的8种CI / CD最佳实践

  • 驱动低代码运动的7种力量

  • 2020年9月TIOBE指数发布,Java流行度降低,C++ 突起

  • 2020年最流行的10个Java框架

  • StringBuider 在什么条件下、如何使用效率更高?

华为鸿蒙系统源码_鸿蒙系统 IO 栈分析 | 解读鸿蒙源码_第13张图片

你可能感兴趣的:(华为鸿蒙系统源码)