[OS_7] 访问操作系统对象 | offset | FHS

实验代码可以看去年暑假的这篇文章：【Linux】进程间通信：详解 VSCode使用 | 匿名管道

我们已经知道，进程从 execve 后的初始状态开始，可以通过 mmap 改变自己的地址空间，通过 fork 创建新的进程，再通过 execve 执行新的程序——我们慢慢已经开始理解 “操作系统上的应用生态“ 并没有魔法了。

本讲内容：操作系统还必须给应用程序提供访问操作系统对象的机制。当然，我们可以直接以 API 的形式提供，例如 Win32 API 包含 “RegOpenKeyEx” 访问注册表。这节课我们学习 UNIX 的 “Everything is a file” 带来的方便 (和不便)。

上一篇文章当中我们讲到过，边写代码边测试非常的重要，那么我们该如何实现测试呢

明确需求

我们需要一个状态 (Everything is a state machine)

- tests 里有全部测试用例且程序还没结束

需要遵守 libc 的约定

- tk_add_test 和 tk_register_hook 执行顺序不确定
- System test 里还可能调用 atexit()

解决问题

tk_register_hook 时立即创建一个进程

- 等程序 atexit() 的时候把 tests 送过来
- 程序之间交换数据：“serialization”（序列化）

Prompt: 有哪些对象 serialization 的通用机制？

常见的对象序列化机制包括：

Java 序列化：使用 Serializable 接口。
JSON：轻量级数据交换格式，广泛用于 Web 开发。
XML：可扩展标记语言，适用于复杂数据结构。
Protocol Buffers：Google 的高效二进制序列化格式。
Avro：Apache 的数据序列化系统，支持动态模式。
MessagePack：二进制 JSON 格式，更高效。
Thrift：Facebook 开发的跨语言序列化框架。

根据需求选择合适的机制。

在这个例子里，因为是完全相同的进程地址空间

我们直接做了一个 “内存复制”，保留了 argv 中指向只读数据的指针。
对于跨应用的对象序列化，则需要做字符串的 deep copy。

我们的做法：利用编程语言机制 hack

并不是好的 practice (但有时候需要)

方法一：请开发者主动调用 API

在 main 里 run_all_tests()
之前学习机 gtest 的时候用的就是这种方法

方法二：提供一个特别的编译器

JavaScript: 这个我懂

方法三：更好的编程语言

JVMTI: Tool Interface

testkit: Writing test cases fearlessly! 这是用于实验的第一个测试框架：支持单元测试和系统测试，自动注册测试用例并在程序退出后运行。

最重要的特点是它使用简单：只需要包含 testkit.h，并且链接 testkit.c 即可。

没有测试过的代码，都是有可能存在问题的！

操作系统中的对象

进程

进程 = 状态机
进程管理 API: fork, execve, exit

连续的内存段

我们可以把 “连续的内存段” 看作一个对象

- 可以在进程间共享
- 也可以映射文件

内存管理 API: mmap, munmap, mprotect, msync

操作系统肯定还有其他对象的！

是如何访问操作系统对象的呢，那通过文件来访问操作系统的对象

文件像键盘显示器也都可以理解为文件，哦我好像知道了
相当于是平时写的代码生成了程序和进程，跑在操作系统这个环境上
然后通过文件来访问这些东西，读取到的结果就是，例如是以我们显示器也是一个文件，来显示出来

7.1 文件描述符

文件和设备

文件：有 “名字” 的数据对象

字节流 (终端，random)
字节序列 (普通文件)

文件描述符

指向操作系统对象的 “指针”

- Everything is a file
- 通过指针可以访问 “一切”

对象的访问都需要指针

- open, close, read/write (解引用), lseek (指针内赋值/运算), dup (指针间赋值)

文件描述符：访问文件的 “指针”

open

- p = malloc(sizeof(FileDescriptor));

- delete(p);

read/write

- *(p.data++);

lseek

- p.data += offset;

- q = p;

在去年暑假，我们手写 shell 的时候，有详细写过这部分的代码，感兴趣的可以去看一下

访问操作系统中的对象--文件描述符

总是分配最小的未使用描述符

0, 1, 2 是标准输入、输出和错误
新打开的文件从 3 开始分配

- 文件描述符是进程文件描述符表的索引
- 关闭文件后，该描述符号可以被重新分配
- Linux 下一切皆文件

进程能打开多少文件？

ulimit -n (进程限制)

sysctl fs.file-max (系统限制)

文件描述符中的 offset

文件描述符是 “进程状态的” 的一部分

保存在操作系统中；程序只能通过整数编号访问
文件描述符自带一个 offset

Quiz: fork() 和 dup()（共享）之后，文件描述符共享 offset 吗？

这就是 fork() 看似优雅，实际复杂的地方

场景	是否共享 offset	原因
独立打开同一文件	❌ 不共享	每个 `open()` 生成独立文件表项
`fork()`	✅ 共享（继承描述符）	子进程复制父进程文件表项，所以他们打开同一文件的话，不会实现覆盖，顶多出现交叉写入
`dup()`	✅ 共享	描述符指向同一文件表项

文件描述符：文件描述符是指向操作系统对象的 “指针”——系统调用通过这个指针 (fd) 确定进程希望访问操作系统中的哪个对象。我们有 open, close, read/write, lseek, dup 管理文件描述符。

Windows 中的文件描述符

Handle (把手；握把；把柄)

比 file descriptor 更像 “指针”
你有一个 “handle” 在我手上，我就可以更好地控制你

Windows 的进程创建

面向工程的设计

默认 handle 是不继承的 (和 UNIX 默认继承相反)

- 可以在创建时设置 bInheritHandles，或者运行时修改
- “最小权限原则”

lpStartupInfo 用于配置 stdin, stdout, stderr

（参考） Windows进程创建的工程化设计核心要点

1. 默认不继承句柄

安全设计：新进程默认不继承父进程的资源访问权限（句柄），防止意外泄露。

按需授权：通过参数 bInheritHandles 或运行时调整，显式指定需共享的资源。

2. 集中式配置入口

统一管理：STARTUPINFO 结构体统一配置子进程的标准输入/输出/错误流，避免参数分散。

模块化扩展：通过结构化字段支持未来功能扩展，降低接口变动风险。

3. 安全与功能的工程权衡

安全优先：相比UNIX默认继承的便利性，Windows更强调最小权限原则（仅开放必要权限）。

灵活控制：开发者可精准指定共享资源，平衡功能需求与安全风险。

Linux 引入了 O_CLOEXEC

fcntl(fd, F_SETFD, FD_CLOEXEC)

//对fd进行各种操作，成功返回0,失败返回-1设errno
#include <unistd.h>
#include <fcntl.h>
int fcntl(int fd, int cmd, ... );		//...表示可变长参数
/*cmd:
Adversory record locking:
F_SETLK(struct flock*)	//设建议锁
F_SETLKW(struct flock*)	//设建议锁，如果文件上有冲突的锁，且在等待的时候捕获了一个信号，则调用被打断并在信号捕获之后立即返回一个错误，如果等待期间没有信号，则一直等待 
F_GETLK(struct flock*)	//尝试放锁，如果能放锁，则不会放锁，而是返回一个含有F_UNLCK而其他不变的l_type类型，如果不能放锁，那么fcntl()会将新类型的锁加在文件上，并把当前PID留在锁上
Duplicating a file descriptor:
F_DUPFD (int)		//找到>=arg的最小的可以使用的文件描述符，并把这个文件描述符用作fd的一个副本
F_DUPFD_CLOEXEC(int)//和F_DUPFD一样，除了会在新的文件描述符上设置close-on-exec
F_GETFD (void)		//读取fd的flag，忽略arg的值
F_SETFD (int)		//将fd的flags设置成arg的值.
F_GETFL (void)		//读取fd的Access Mode和其他的file status flags; 忽略arg
F_SETFL (long)		//设置file status flags为arg
F_GETOWN(void)		//返回fd上接受SIGIO和SIGURG的PID或进程组ID
F_SETOWN(int)		//设置fd上接受SIGIO和SIGURG的PID或进程组ID为arg
F_GETOWN_EX(struct f_owner_ex*)	//返回当前文件被之前的F_SETOWN_EX操作定义的文件描述符R
F_SETOWN_EX(struct f_owner_ex*)	//和F_SETOWN类似，允许调用程序将fd的I/O信号处理权限直接交给一个线程，进程或进程组
F_GETSIG(void)		//当文件的输入输出可用时返回一个信号
F_SETSIG(int)		//当文件的输入输出可用时发送arg指定的信号
*/

/*…: 	
可选参素，是否需要得看cmd，如果是加锁，这里应是struct flock*
struct flock {
	short l_type;	//%d Type of lock: F_RDLCK(读锁), F_WRLCK(写锁), F_UNLCK(解锁)
	short l_whence;	//%d How to interpret l_start, 加锁的位置参考标准:SEEK_SET, SEEK_CUR, SEEK_END
	off_t l_start;  //%ld Starting offset for lock, 	加锁的起始位置
	off_t l_len;    //%ld Number of bytes to lock , 锁定的字节数
	pid_t l_pid;   	// PID of process blocking our lock, (F_GETLK only)加锁的进程号,,默认给-1
};
*/

文件描述符：文件描述符是指向操作系统对象的 “指针”——系统调用通过这个指针 (fd) 确定进程希望访问操作系统中的哪个对象。

Filesystem Hierarchy Standard --FHS

enables software and user to predict the location of installed files and directories: 例如 macOS 就不遵循 FHS

只要拷对了文件，操作系统就能正常执行啦！

创建 UEFI 分区，并复制正确的 Loader
创建文件系统

- mkfs (格式化)

cp -ar 把文件正确复制 (保留权限)

- 注意 fstab 里的 UUID
- 就得到了一个可以正常启动的系统盘！

运行时挂载必要的其他文件系统

- 磁盘上的 /dev, /proc, ... 都是空的
- mount -t proc proc /mount/point 可以 “创建” procfs

对于Linux制作系统盘的实验前文有写过，感兴趣的可以找着看一下Linux 系统盘制作 | 引导加载器(GRUB 为例）| mount

操作系统给了我们很多API，可以创建各种各样的对象

任何 “可读写” 的东西都可以是文件

真实的设备

/dev/sda
/dev/tty

虚拟的设备 (文件)

/dev/urandom (随机数), /dev/null (黑洞), ...

- 它们并没有实际的 “文件”
- 操作系统为虚拟的设备 (文件)实现了特别的 read 和 write 操作

- - /drivers/char/mem.c
  - 发现的一些有意思的事情：甚至可以通过 /sys/class/backlight 控制屏幕亮度

procfs 也是用类似的方式实现的

管道：一个特殊的 “文件” (流)

由读者/写者共享

- 读口：支持 read
- 写口：支持 write

匿名管道

(Unix得图灵奖的一个重要原因🙂

返回两个文件描述符
进程同时拥有读口和写口

- 看起来没用？不，fork 一下就有用了 (testkit)

然后甚至还可以再结合dup，来实现对 0 1 2 指向替代也可以
ls | wc -l (这就是一个管道的应用)

⭕理解管道的意义：

UNIX 管道：UNIX 管道 (pipe) 是一种典型的进程间通信机制，允许数据在不同的进程之间单向流动。
管道可以被视为一种特殊的文件，其中一个进程将数据写入管道的一端，而另一个进程从另一端读取数据。

管道实现了父子进程当中，先后的同步。

⭕sum

进程管理

fork, execve, waitpid, exit

内存管理

mmap, munmap, mprotect, msync

文件管理

open, close, read, write, lseek, dup

mkfifo 命名管道，可以属于某一个文件
pipe 匿名管道。

proc
sys
Everything is a File ...

例如来和 ag 结合，cat readme.md | ag 就可以问AI 啦

一切皆文件的好处

一套 API 访问所有对象

一切都可以 | grep

- Introducing ag -g

同时，UNIX Shell 的语法广受诟病

稍大一些的项目就应该用更好的语言 (Python, Rust!)
但是：We all love quick & dirty!

ls -l /proc/*/fd/* 2>/dev/null | awk '{print $(NF-2), $(NF-1), $NF}'
grep -s VmRSS /proc/*[0-9]/status | awk '{sum += $2} END {print sum " kB"}'

Prompt: 什么是 glob patterns? 有什么实际中常用的扩展？

Glob patterns 是一种用于匹配文件路径名的模式，常用于文件搜索和操作。常见的通配符包括：

*：匹配任意数量的字符（包括零个）
?：匹配单个字符
[]：匹配指定范围内的字符

实际中常用的扩展包括：

**：递归匹配任意层级的子目录
{}：匹配多个模式，如 {a,b,c} 匹配 a、b 或 c
!(pattern)：排除指定模式

这些扩展增强了 glob patterns 的灵活性和功能性。

字节流

顺序读/顺序写

- 没有数据时等待
- 典型代表：管道
- 但是会存在操作系统对offset默默地移动...

字节序列

其实就有一点点不方便了

- 需要到处 lseek 再 read/write

- - mmap 不香吗？指针指哪打哪
  - madvise, msync 提供了更精细的控制

lseek 用于重新定位文件偏移量（文件指针位置），支持三种定位模式：

SEEK_SET：绝对定位（从文件头开始偏移）

SEEK_CUR：相对定位（从当前位置偏移）

SEEK_END：从文件末尾偏移

补充说明：该函数不会触发任何物理 I/O 操作，仅修改内核中的文件偏移量记录。

优点

优雅，文本接口，就是好用

缺点

和各种 API 紧密耦合

- A fork() in the road

im ple men ta tion 实现
al ter na tives 替代方案
con flates 合并

如果我fork出的父子进程，同时写Hello和world，它会是覆盖呢还是实现延续呢?

进程独立性
fork()会创建子进程，父子进程的内存空间是独立的，但文件描述符（如标准输出）是共享的。因此，两者的输出会混合到同一个目标中，但不会直接覆盖（每个write操作是原子的）
输出顺序不确定
父子进程的执行顺序由操作系统调度决定。可能的结果包括：

- 父进程先输出“Hello”，子进程后输出“World” → HelloWorld
- 子进程先输出“World”，父进程后输出“Hello” → WorldHello
- 两者交替执行，导致字符交错（如HWeolrllod）

对高速设备不够友好（why)

- 额外的延迟和内存拷贝
- 单线程 I/O

Any problem in computer science can be solved with another level of indirection. (Butler Lampson)

Windows NT: Win32 API → POSIX 子系统

- Windows Subsystem for Linux (WSL)

macOS: Cocoa API → BSD 子系统
Fuchsia: Zircon 微内核 → POSIX 兼容层

兼容当然没法做到 100%

sysfs, procfs 就是没法兼容
优雅的 WSL1 已经暴毙

- “Windows Subsystem for Linux”
- “Linux Subsystem for Windows” (wine)
- 对硬件做抽象，给应用程序提供服务

拓展： OpenHarmony

对于硬件和软件

“初学FPGA，突然顿悟何为“硬件的并行化思维”的美妙，那一瞬之后，就像打通了任督二脉，之后不管是看代码还是写代码都变得十分顺畅。更关键的是我的认知也得到了提升：那是我第一次认知到不同思维模式会对coding产生如此之大的区别。
其实反过来各种语言也在（强迫）塑造人的思维模式，比如cuda之类的并行编程要求程序员转换思维模式。HDL也一样。人发明工具，然后被工具改变。
以除法为例，软件工程师代码的除法： int val=3300/256 ; 硬件工程师：int val = 3300》8；“

[OS_7] 访问操作系统对象 | offset | FHS | Handle