当前位置：首页 > article >正文

32、【OS】【Nuttx】OSTest分析（1）：stdio测试（二）

article 2025/1/27 3:57:10

背景

接上篇wiki
31、【OS】【Nuttx】OSTest分析（1）：stdio测试（一）
继续stdio测试的分析，上篇讲到标准IO端口初始化，单从测试内容来说其实很简单，没啥可分析的，但这几篇分析的 wiki 会另辟蹊径，从文件系统的角度进行分析标准IO端口的初始化过程，后续再分析文件系统的时候，相关知识点会直接引用这几篇wiki，重复内容不会再出现

标准IO端口初始化

之前介绍了文件系统中 filelist 队列，下面分析 filelist 队列里面的核心成员 fl_files

file 结构体

之前wiki说过，核心成员 fl_files 为一个二维数组指针，指向了存放文件实例的内存区域，用户通过文件描述符 fd 可以索引到对应的文件实例，索引方法为 fl_files[fd / BLOCK_SIZE][fd % BLOCK_SIZE]
在这里插入图片描述

必选成员

核心成员 fl_files 的类型定义如下，首先看里面的4个必选成员 f_oflags，f_pos，f_inode，f_priv，其中核心成员的是 f_inode，f_inode 体现了文件系统中拓扑结构：
在这里插入图片描述

f_oflags：文件的打开模式标志，决定了文件可以如何被访问（比如只读只写，可读可写，创建文件等等），解释起来比较绕，可以直接来看这个标志都支持哪些模式。查看其模式定义如下，其中大部分模式是基于 POSIX 标准的，只有少数几个是Nuttx独有的，比如 O_RDOK，O_WROK（应该是拿来做兼容的），这意味着大部分这些打开模式，在类Unix系统，比如Linux中也存在
f_pos：文件偏移量，表示文件当前的读写位置，对顺序读取和写入很重要，有几个关键点：
1、初始值：当文件首次打开时，f_pos 通常被初始化为 0，表示文件的开头；如果文件以追加模式打开（如上面模式定义的O_APPEND），那在每次写入之前，f_pos 会被自动设置为文件末尾，这点代码也能看出来

2、文件读取：从文件读数据时，f_pos 指定了从哪个字节开始读。每次成功调用读取函数（如 host_read()），f_pos 会自动增加所读取的字节数，这点随便找一个文件系统就能看出来，比如hostfs

3、文件写入：和文件读取一样，在写数据到文件时，f_pos 确定了数据应该被写入的位置。每次成功调用写入函数（如 host_write()），f_pos 也会相应地增加
f_inode：file 类型中的核心成员，体现了文件系统中拓扑结构，在 Nuttx 中，每个文件和目录都有一个对应的inode。这个特定的 inode 包含了描述文件或目录所需的信息，它包含了文件的元数据，比如节点名字，层次关系、操作函数、时间戳等，在文件系统内部使用，用户通常不会直接与之交互。用户一般通过标准的文件系统API（如open, read, write等）来间接操作该数据结构。如下图所示，当用户想要注册一个文件C时，其路径为 /A/B/C，此时文件系统会自动创建三个节点：A/B/C，B/C，C，其中 A/B/C 是 B/C 的父节点，B/C 是 C 的父节点，且 A/B/C 和 /B/C 均为目录节点，C 为文件节点，最终在 C 节点上添加更详细的节点信息，如名字，操作函数等。
f_priv：每次打开文件时特有的私有数据（注意：inode 中也有 i_private 成员，两者的差别在于，f_priv 为每个单独的实例用户提供私有空间，以保存仅对该次打开有效的数据，i_private 为整个 inode 节点的提供全局性私有数据），如图所示，不同用户可以通过不同的文件实例，操作同一个节点：

可选成员

下面来看下 file 类型的可选成员，可选成员通过配置项来决定是否启用，有 f_refs，f_tag_fdsan，f_tag_fdcheck，f_backtrace，locked 等五个成员
在这里插入图片描述

f_refs：通过使用方式可以看到该成员为原子变量类型，用来追踪引用该文件结构的次数，以实现文件共享访问，确保所有对该文件的引用都消失时，再安全地释放资源。

在多核环境中，不同进程或线程可能需要同时访问同一个文件，这种共享访问须确保安全性和一致性。当用户打开一个文件时，实际上是通过文件描述符来操作文件实例，而此时另一用户也可通过相同的文件描述符来操作该文件实例。
f_refs 成员作为原子类型的引用计数器，记录有多少个用户正在引用该文件实例，每当一个新用户打开该文件时，引用计数增加；而当用户关闭该文件时，引用计数减少，当所有用户都关闭了该文件时，Nuttx 才会认为可以安全清理和释放该文件实例下的相关资源（如内存、缓冲区等）。
f_tag_fdsan：英文全名 sanitizer ，一种并发编程中的检测工具，tsan 和 asan 比较常见
1、tsan（thread sanitizer ）用来检测并发编程中的数据竞争和死锁等问题
2、asan（address sanitizer ）用来检测内存越界、内存泄漏、使用已释放内存等问题
3、fdsan（file description sanitizer ）用来检测和防止文件描述符的误用问题
具体来说，有如下检测场景：
一、防止文件实例被重复打开：可以看到，每当打开一个新文件时，f_tag_fdsan 将被 android_fdsan_exchange_owner_tag 设置成一个非0值，如果还有用户尝试打开该文件时，此时由于 f_tag_fdsan 非0，Nuttx 将进入 PANIC 恐慌

流程图如下：