Fork

上一章实现了 TCP/IP 栈，用户程序能发 HTTP 请求了。但验证时发现 /bin/ls 完全没反应，wget_test 也跑不起来。这一章记录排查过程——一共修了 6 个 bug，涉及 ext2 fast symlink、VFS 路径解析、内核栈溢出、缺失 syscall，以及两个调度器 cpu_pin 问题。 最终效果： / # ls bin etc lost+found / # cd bin /bin # ls busybox cp kill mv pwd sh wget_test cat echo ls ps rm umount /bin # wget_test wget_test start connecting... connected! request sent HTTP/1.0 200 OK ... DONE /bin # 背景：busybox 的目录结构 Makefile 用这种方式制作 ext2 镜像： sudo cp busybox-x86_64 /tmp/ext2mnt/bin/busybox sudo cp busybox-x86_64 /tmp/ext2mnt/bin/sh # sh 是真实复制 for cmd in ls cat echo pwd ...; do sudo ln -sf /bin/busybox /tmp/ext2mnt/bin/$cmd # 其他命令是符号链接 done /bin/sh 是真实文件，/bin/ls 等是指向 /bin/busybox 的符号链接。 ...

上一章实现了阻塞式 TTY，这一章在同样的思路上让 pipe 的 read 也变成阻塞式，同时修复了调度器里隐藏的两个 Bug，让 fork + exec + wait4 的完整流程跑通。 问题：非阻塞 pipe read 的后果 ch33 之前，vfs_read 对 pipe 的实现是： if (pipe_buf_empty(p)) return 0; // 管道空 → 直接返回 0 对于 shell 管道命令，busybox sh 会： fork 出子进程执行左侧命令，写 pipe 父进程（或另一子进程）读 pipe，处理右侧命令 如果读端在写端还没写入时就读到 0，shell 认为 EOF，管道提前关闭，命令输出丢失。 解决方案：sti/hlt 等待 与 ch33 阻塞式 TTY read 相同的思路：在内核态用 sti; hlt 轮询等待。 // pipe read：等待数据或写端关闭 while (pipe_buf_empty(p) && pipe_has_writer(p)) { __asm__ volatile("sti" ::: "memory"); __asm__ volatile("hlt" ::: "memory"); __asm__ volatile("cli" ::: "memory"); } if (pipe_buf_empty(p)) return 0; // 写端已关闭且无数据 → EOF 关键点： ...

上一章每个进程有了自己的地址空间。这一章实现 fork()——创建一个子进程，继承父进程的全部内存。 最朴素的 fork 实现 fork 的语义是"完整复制当前进程"。最直接的做法：遍历父进程页表，找到每一个物理页，分配新页，复制 4096 字节内容，给子进程建新映射。 能用，但很浪费。大多数 fork() 之后会紧接着 exec()——旧内存根本用不上，全拷了白拷。进程堆如果有几十 MB，每次 fork 都要等好几毫秒。 Copy-on-Write：先共享，写了再分 CoW 的思路是：fork 时不复制，让父子共享同一批物理页；等到谁要写，再给他一份新的。 实现上分两步： 第一步：fork 时打标记 遍历父进程用户页表，对每一页做两件事： 清掉 WRITABLE 位，变成只读 打上 PAGE_COW 标志（借用 x86 页表的 bit 9，这一位 CPU 不使用，留给软件自定义） 子进程页表复制同一个物理页地址，同样只读 + CoW。 fork 后： 父进程 → PT → 物理页 0xA000 (只读, CoW) ↑ 共享 子进程 → PT → 物理页 0xA000 (只读, CoW) 注意一个关键细节：PDPT/PD/PT 这三级结构页必须为子进程单独分配。如果父子共用同一棵结构树，后续 vmm_map_page 修改子进程时会把父进程的 PT 一起改掉，隔离失效。数据页可以共享，结构页不能。 另一个细节：改完父进程页表后必须刷新 TLB。否则 CPU 缓存里还是旧的可写映射，父进程写该页不会触发 fault，CoW 形同虚设。 ...