Posts on 大飞的博客

LLMLingua：用小模型压缩 Prompt，省 95% Token

Wed, 03 Jun 2026 10:00:00 +0000

调研范围：LLMLingua 系列（v1 / LongLLMLingua / LLMLingua-2）项目背景、技术演进、性能数据、横向对比、工程落地
主要文献：arXiv:2310.05736（EMNLP 2023）、arXiv:2310.06839（ACL 2024）、arXiv:2403.12968（ACL Findings 2024）

一、项目背景与核心原理

1.1 动机：Prompt 膨胀是 LLM 落地的成本瓶颈

CoT、ICL、RAG 等技术的普及使 prompt 长度从几百 token 迅速膨胀到数万 token。按 GPT-4 计费标准，一次请求仅 prompt 成本就可能达 $0.3–$1+。企业级应用中，80% 的 token 开销往往集中在冗余的上下文内容里。

技术范式	对 Prompt 的影响
In-Context Learning (ICL)	注入多个 few-shot 示例，每个示例 300–600 token
Chain-of-Thought (CoT)	完整推理链进一步增大示例体积
RAG（检索增强生成）	每次请求注入若干检索文档段落
Agent / 工具调用	System prompt + 对话历史 + 工具描述累积

三类影响：

成本：Token 按量计费，压缩 20× 可节省约 95% 的 input token 费用
延迟：prefill 阶段与输入长度正相关，长 prompt 直接拉高首 token 延迟（TTFT）
准确率：超长上下文有 “lost-in-the-middle” 问题——LLM 对中间位置的信息关注度显著低于首尾

1.2 核心洞察：用小模型 PPL 代理信息量

LLMLingua 的根本思路是：用廉价的小语言模型（GPT-2/LLaMA-7B）计算 token 的困惑度（Perplexity），以此作为信息重要性的代理。

自制 x86-64 内核（46）：mmap 文件映射

Wed, 03 Jun 2026 00:00:00 +0000

上一章实现了 TCP 服务端，这章来实现一个经典的内存管理功能：mmap 文件映射。

什么是 mmap 文件映射

mmap 把文件的一段内容映射到进程的虚拟地址空间。映射后可以像读内存一样读文件——不需要 read() 系统调用，直接解引用指针。

int fd = open("/bin/busybox", O_RDONLY);
char *p = mmap(NULL, 4096, PROT_READ, MAP_PRIVATE, fd, 0);
// p[0..3] 就是文件的前 4 字节（ELF magic: 7f 45 4c 46）

关键设计：VMA 和 Lazy 分配

mmap 不会立刻分配物理内存，而是登记一个 VMA（虚拟内存区域），等到进程真正访问这段地址时，才通过缺页异常按需读取文件内容并建立页表映射。

mmap(fd) → 注册 VMA（vaddr, len, inum, offset） → 返回虚拟地址
                        ↓ 进程访问该地址
              #PF not-present → 找到 VMA → 分配物理页
                              → ext2_read(inum, offset, page)
                              → 建立页表 → 重试指令

这就是操作系统课上说的"按需分页"（demand paging）。

实现步骤

1. 定义 VMA 结构

在 process_t 中加入 VMA 数组：

自制 x86-64 内核（47）：动态链接器基础

Wed, 03 Jun 2026 00:00:00 +0000

这一章实现了对 PIE（Position-Independent Executable）程序的支持，也就是不加 -static 编译出来的"动态"程序。

问题：PIE 和静态 ELF 的区别

用 musl-gcc 编译一个简单的 hello world：

# 静态（之前一直用的）
musl-gcc -static -O2 -o hello hello.c
# 动态（PIE）
musl-gcc -O2 -o hello_pie hello.c

file 查看：

hello:     ELF 64-bit LSB executable, x86-64, statically linked
hello_pie: ELF 64-bit LSB pie executable, x86-64, dynamically linked

区别在于：

属性	静态 (ET_EXEC)	PIE (ET_DYN)
`e_type`	`2`	`3`
虚地址	固定（如 0x400000）	从 0 开始，需加载时指定 base
重定位	无	`.rela.dyn` 表
外部依赖	无	通常有（但 musl PIE 已内嵌 libc）

为什么 musl PIE 没有"真正的"动态链接？

musl-gcc 默认把所有 libc 代码静态链接进去，只是编译为 PIE 格式（支持 ASLR）。所以运行时：

从零写OS（四十五）：TCP 服务端——bind/listen/accept

Tue, 02 Jun 2026 11:00:00 +0000

前面几章都是做 TCP 客户端——发 SYN、连接、发请求、收响应。这章反过来，让内核能作为 TCP 服务端：监听端口，接受连接，响应请求。

客户端 vs 服务端的区别

客户端：主动发 SYN，等待 SYN-ACK。

服务端：被动等待 SYN，收到后发 SYN-ACK，等 ACK 完成三次握手，然后通过 accept() 把新连接交给应用层。

关键区别在于：服务端有两种 socket 角色——

角色	职责
监听 socket（listen fd）	绑定端口，等待连接请求
连接 socket（accept fd）	每个客户端连接对应一个，负责实际数据收发

三步接口

bind(fd, &sa, len)    // 绑定本地端口
listen(fd, backlog)   // 进入监听状态
accept(fd, &sa, &len) // 阻塞，等到有连接，返回新 fd

数据结构

tcp_sock_t 加了几个字段：

int  is_listener;
int  accept_queue[8];   // 存已完成三次握手的连接 index
uint32_t accept_head, accept_tail;

还新增了两个状态：

TCP_LISTEN：监听中，等待 SYN
TCP_SYN_RECV：收到 SYN 已回 SYN-ACK，等最终 ACK

核心流程

1. 收到 SYN

tcp_handle() 里单独处理 SYN：

if ((tcp->flags & TCP_SYN) && !(tcp->flags & TCP_ACK)) {
    // 找到监听该端口的 socket
    // 分配新连接 slot
    ns->state       = TCP_SYN_RECV;
    ns->local_port  = dport;
    ns->remote_port = sport;
    ns->remote_ip   = src_ip;
    ns->ack         = ntohl(tcp->seq) + 1;  // 下次要 ACK 的序号
    ns->syn_seq     = 0xABCD1234;
    ns->snd_una = ns->snd_nxt = ns->syn_seq;
    tcp_send_seg(ns, ns->syn_seq, TCP_SYN | TCP_ACK, 0, 0);
}

2. 收到最终 ACK（完成三次握手）

if (s->state == TCP_SYN_RECV && (tcp->flags & TCP_ACK)) {
    if (ack_val == s->syn_seq + 1) {
        s->snd_una = s->snd_nxt = ack_val;
        s->state = TCP_ESTABLISHED;
        // 放入监听 socket 的 accept queue
        ls->accept_queue[ls->accept_tail % 8] = i;
        ls->accept_tail++;
    }
}

3. accept() 取连接

int tcp_accept(int s, ...) {
    tcp_sock_t *ls = &tcp_socks[s];
    while (ls->accept_head == ls->accept_tail) {
        sti; net_poll(); cli;   // 阻塞等待
    }
    int ni = ls->accept_queue[ls->accept_head++ % 8];
    return ni;
}

测试

写了一个简单的 HTTP 服务端程序：

从零写OS（四十四）：UDP Socket + DNS 解析

Tue, 02 Jun 2026 10:00:00 +0000

上一章（四十三）把 TCP 重传做好了。这一章加两个新功能：UDP socket 用户空间接口 和 DNS 解析 syscall，让用户程序可以用域名来连接服务器。

目标

内核里其实早就有 udp_send 和 dns_resolve 这两个函数了，但用户程序用不到，因为没有对应的 syscall。这章要做的就是把这两个内核能力"打通"到用户空间：

socket(AF_INET, SOCK_DGRAM, 0) → 分配一个 UDP socket，返回 fd 200+
sendto / recvfrom → 通过 UDP socket 收发数据
SYS_DNS_RESOLVE（自定义 syscall 500）→ 通过域名查 IP

UDP Socket 设计

UDP 比 TCP 简单很多：无连接、无状态机、无重传。核心是一个接收队列：内核收到 UDP 包时，把它放进对应 socket 的队列，用户程序再来取。

typedef struct {
    uint32_t src_ip;
    uint16_t src_port;
    uint16_t len;
    uint8_t  data[512];      // 每个包最多 512 字节
} udp_pkt_entry_t;

typedef struct {
    int              used;
    uint16_t         local_port;
    udp_pkt_entry_t  queue[4];  // 最多暂存 4 个包
    uint32_t         qhead, qtail;
} udp_sock_t;

队列用无限增长的 qhead/qtail 计数（不是环形下标），访问时用 % UDP_PKT_MAX，满了就丢包：

源码分析（一）：Netflix Headroom 是怎么把 LLM 账单砍掉一半的

Tue, 02 Jun 2026 10:00:00 +0000

最近看到一个叫 Headroom 的项目，Netflix 高级工程师 Tejas Chopra 个人开源的，号称能帮你把发给 LLM 的 token 减少 30-70%，而且不丢信息。

我把源码读了一遍，发现里面有几个设计很有意思，记下来。

项目地址：https://github.com/chopratejas/headroom

本文分析的主要源文件：

headroom/transforms/content_router.py — 内容识别与路由
headroom/transforms/content_detector.py — 内容类型检测
crates/headroom-core/src/transforms/smart_crusher/ — SmartCrusher Rust 实现
crates/headroom-core/src/transforms/log_compressor.rs — 日志压缩 Rust 实现
headroom/transforms/cache_aligner.py — CacheAligner
headroom/ccr/tool_injection.py — CCR 工具注入

它解决的是什么问题

你在用 Claude 或 GPT 做 agent 的时候，工具调用（tool call）的返回结果会吃掉大量 token。

比如你让 agent 查数据库，返回了 500 条记录，每条有 15 个字段。但其中 12 个字段在所有记录里都是完全相同的值，真正有用的只有 3 个字段。你把 500 × 15 的数据全塞给 LLM，它实际只需要 500 × 3。

这就是浪费。Headroom 做的事，就是在你把数据发给 LLM 之前，先把这些废话压掉。

tclaw（五）：接入飞书、语音、图片

Tue, 02 Jun 2026 05:00:00 +0000

让 AI 融入日常

桌面应用之外，tclaw 还支持通过飞书和微信直接和 agent 对话。

飞书

飞书有开放平台，可以创建自己的机器人。tclaw 接入之后，在飞书里和 tclaw 对话，就相当于在桌面应用里聊天，但可以用手机。

支持的能力：

发文字消息，agent 回复
发图片给 agent，agent 可以分析图片内容
agent 可以把生成的图片发回飞书

微信

微信这边不需要额外配置，在设置里开启微信，直接扫页面上的二维码登录，之后就可以在微信里和 agent 对话了。

图片输入与截图

桌面端也补全了多模态能力：

聊天框可以直接粘贴或拖入图片发给 agent
内置截图工具，可以截当前屏幕，裁剪、标注之后直接发给 agent
agent 可以调用图片生成工具，生成的图片直接显示在对话里

图片生成

接了两个图片生成后端：

Ollama：本地跑，不花钱，速度慢一点
外部 API：质量更好，按量计费

agent 可以在任务里直接调用图片生成，比如写完一篇文章顺手配一张封面图。

tclaw 提供 Mac、Linux、Windows 版下载，Mac 版支持最好，感兴趣可以去 tclaw-releases 体验。

也可以先玩玩 tclaw 用 AI 做的几个小游戏：→ 点这里玩

tclaw（四）：从能用到好用

Tue, 02 Jun 2026 04:00:00 +0000

能用只是开始

内核稳定之后，tclaw 已经能干活了。但"能用"和"好用"之间，有很长一段路。

用着用着，各种不顺手的地方就冒出来了。agent 生成的文档没法方便地看；上下文长了之后 token 烧得很快；只有命令行，想给别人用很难；文件多了之后找东西很费劲……

接下来花了差不多一个月的时间，一件一件地打磨。

Wails 桌面应用

首先是 GUI。自己用命令行没问题，但如果想让更多人用，得有个像样的界面。

调研了一圈，选了 Wails——用 Go 写后端，前端是普通的 HTML/JS，打出来是一个原生桌面应用，体积小，对 Go 友好。最终打包出来的 Mac 应用只有几十 MB，不需要用户装任何运行时。

同一套 HTML，既可以跑在 Wails 桌面里，也可以用浏览器直接访问。

预览面板

agent 经常帮我生成文档、写 HTML 页面、画 mermaid 流程图。生成完要看效果，之前要自己去找文件打开，很麻烦。

做了一个右侧预览面板：

Markdown 文件直接渲染，支持 mermaid 图表
HTML 文件直接在面板里预览网页效果
图片直接显示
还可以在预览内容上框选区域，加标注，直接发给 AI 问问题

文件浏览器

本地文件多了之后，找东西很头疼。做了一个内置的文件浏览器，可以快速搜索文件，并且直接在里面预览：

Excel 打开直接显示表格
JSON/XML 显示树形结构，可以展开折叠
zip/tar 显示压缩包内容列表
SVG 可以缩放拖拽
PDF、图片、音视频都能预览

还加了文件格式转换和压缩功能，平时用得上的小工具基本都有了。

上下文管理

用 LLM 最头疼的问题之一是上下文窗口。对话长了，token 烧得很快，而且超出窗口就报错。

做了几件事：

自动剪裁：上下文快满的时候，自动把旧的 tool result 压缩，保留关键内容
保留读取位置：被剪裁的内容不是直接丢掉，而是记录偏移量，agent 需要的时候还能用 offset 继续读
cache 优化：加了多个 cache breakpoint，反复用的内容不重复计费
token 看板：侧边栏可以实时看每轮的 token 消耗，一眼就知道上下文用了多少

VSCode 风格布局

界面改版了一次，改成 VSCode 风格的 Activity Bar + Side Panel 布局：

tclaw（三）：重构——换一种方式让 Agent 协作

Tue, 02 Jun 2026 03:00:00 +0000

问题出在哪里

消息总线那套方案放弃之后，我坐下来想了一下，问题到底出在哪。

根本原因是：消息总线是对等的，每个 bot 都可以给任何人发消息。这种自由度在人类团队里没问题，因为人有判断力，知道什么时候该说话、什么时候不该插嘴。但 LLM 不一样，它的"判断"是概率性的，今天遵守规则，明天又忘了。你加再多提示词约束它，它该乱的时候还是会乱。

既然对等通信管不住，那就换成单向调用——上级调下级，下级只干自己的事，不主动找别人。

新的设计

重构后的 tclaw，多 agent 协作的方式变成了这样：

list_categories → list_agents → run_agent

用户或者顶层 agent 先用 list_categories 看看现在有哪些领域，再用 list_agents 列出某个领域下的所有 agent，然后用 run_agent 调用具体的 agent 去做事。

就像公司里的层级结构：你要找人做事，先找到对应的部门，再找到对应的人，直接下任务。这个人完成任务后把结果交回来，不会自己跑去找别的部门。

这样一来，协作的控制权始终在调用方手里，被调用的 agent 只负责完成自己的任务，不能主动发起新的协作链路。

pcclaw → tclaw

这次重构等于把整个架构重新来过，代码改动很大，干脆起了个新名字：tclaw。t 是我名字的首字母。

2026 年 4 月 21 日，tclaw 第一次提交。从 pcclaw 的第一次提交到现在，差不多过了五周。

新架构稳定多了。agent 之间的协作变得可预测，出了问题也知道去哪里找。当然也不是完美的——有时候顶层 agent 该调用专业 agent 的时候，它自己就把事情做了，没有委托出去。但比起消息总线那套，已经好太多了。

同期做的其他事

重构完内核，顺手把周边也整理了一遍：

把引擎抽成独立包，方便后续扩展
加了 WebSocket server，可以用浏览器访问
做了 WebGUI，有 tool call 展示
加了 session 历史侧边栏
做了 onboarding wizard，引导新用户配置

从只能在命令行用的小工具，开始变成一个像样的产品。

tclaw（二）：多 Agent 协作，以及那三周的噩梦

Tue, 02 Jun 2026 02:00:00 +0000

一个 agent 不够用

pcclaw 能跑起来之后，用起来还挺顺手的。让它帮我写代码、查文档、跑脚本，基本的事情都能做。

我们平时需要专业的事交给专业的 agent，写代码有 coder，做设计有 designer，管任务有 captain。但问题是每次都要自己指定去找哪个 agent，用起来很麻烦。

能不能让 agent 自己知道该找谁？

消息总线的设计

当时的想法是：做一个消息总线，每个 bot 都挂在上面，bot 之间通过发消息协作。想让某个 bot 做事，就发一条消息 @ 它。

角色大概是这样分的：

captain：大管家，负责整理思路、拆解任务、协调全局
coder：负责开发，下面还有 architect、implement、review、tester 等子 agent
design：负责设计文档
content：负责内容创作
……

这套东西用起来有段时间感觉相当爽。我可以在开车的时候通过飞书和 captain 对话，让它帮我整理一个想法，captain 觉得需要技术方案就会 @ coder，coder 内部再分工，architect 写设计、implement 写代码、review 检查。我只需要说一句需求，后面的事 captain 去协调。

有段时间我迷上了让 pcclaw 开发 pcclaw。感觉挺厉害，但其实还是 claude 更强些。不过自家的孩子，总是最好的。

后来我给 pcclaw 取名叫"咖啡"——一边喝咖啡，咖啡自己就把活干完了的意思。

那段时间每天早上 6 点起床弄咖啡，弄到 8 点再洗漱吃饭，时间卡得很紧。路上也闲不住，一边开车一边用飞书和咖啡聊，想到什么就说，让它做调研、出方案，顺手 PUA 它让它好好干活。

那段时间晚上 1 点多才睡，第二天 4 点 20 就自然醒了——也不敢起来，怕一起来就睡不着了，毕竟还得上班。就躺着，脑子里转的全是给 pcclaw 加什么功能。

直到有天早上开车时候睡着了。感觉睡了 2 秒钟，眼睛睁开车已经偏了，还好刚下高速，车速不快，但还是挺后怕的。然后就老实了，7:30 起床，保命要紧。

tclaw（一）：过年玩 OpenClaw，玩着玩着就自己造了一个

Tue, 02 Jun 2026 01:00:00 +0000

过年

2026 年春节，OpenClaw 火了。

其实年前就已经有很多人在玩了，但我那时候忙，没时间搭理。正好赶上过年，难得有几天清闲，就把 OpenClaw 装上玩了一下。

这一玩就收不住了。整个过年，家人吃饭我在玩，大年初几我也忘了，反正就是一直在玩。

玩了一段时间，自然就开始好奇它内部是怎么工作的：这东西怎么知道该调用哪个工具？记忆是怎么管理的？提示词是怎么组织的？就让 AI 帮我分析了一下源码。

发现 pi-mono

顺着 OpenClaw 的源码往里翻，发现它的内核依赖一个叫 pi-mono 的东西。

去看了 pi-mono 的代码，感觉设计很精干。它不是一个框架，只提供必要的东西：一个 Agent 循环、工具调用、会话管理，仅此而已。没有编排 DSL，没有 workflow 引擎，没有各种抽象层。核心思想就是：

把工具给大模型，让它自己决定怎么解决问题。

然后看了一下 pi-mono 的作者背景，发现是游戏开发者出身。我自己以前也做过游戏，看到这里有点感慨——牛人到哪都是牛人。

pcclaw 诞生

年后大家都在玩 OpenClaw，不知道怎么抽风了，想用 Go 实现一下 pi-mono 内核，看看它到底怎么运行的。

我平时写 Go，OpenClaw 是 JS 的，语言上的迁移借助 AI 不是太大的问题，主要还是要把原理搞清楚。2026 年 3 月 15 日，pcclaw v0.0.1 第一次提交。

pcclaw，tclaw 的前身。

架构上参考了 OpenClaw 的分层思路：

tool → command → skill → agent

tool：最底层，封装基础操作（bash 执行、文件读写、网络请求等）
command：把 tool 组合成更高层的操作
skill：可复用的能力单元，agent 通过调用 skill 完成任务
agent：顶层，接收用户指令，通过 skill 和 tool 解决问题

Provider 层支持多种协议——OpenAI compatible、Anthropic 等，可以接不同的模型。内核沿用 pi-mono 的思路：LLM 发现问题 → 调用 tool → 检查结果 → 继续或结束。就是一个循环，没有更多了。

从零写OS（四十三）：TCP 重传 —— 丢包了也能传完

Mon, 01 Jun 2026 10:00:00 +0000

上一章（四十二）修了一堆 busybox 相关的 bug，让 ls/exec/wait 都能正常工作，wget_test 也能跑通 HTTP。但那时的 TCP 实现有个隐患：一旦丢包，传输就会永远卡住。这一章把重传机制做完整。

原代码的问题

ch42 的 tcp_send_raw 函数身兼数职：构造 TCP 包、发送、存入发送缓冲区、推进 snd_nxt。

static void tcp_send_raw(tcp_sock_t *s, uint8_t flags, const void *data, uint16_t dlen) {
    ...发包...
    if (dlen) {
        ...存 sbuf...
        s->snd_nxt += dlen;
    }
    if (flags & (TCP_SYN | TCP_FIN)) s->seq++;   // 推进 seq
    if (dlen) s->seq += dlen;                     // 又推进一次！
}

问题一：seq 和 snd_nxt 是两个字段，但都在追踪"下一个要发的序号"，语义重复，而且 seq 被推进了两次（SYN/FIN 一次、数据一次）。

问题二：重传时的代码非常丑陋：

uint32_t saved_seq = s->seq;
uint32_t saved_nxt = s->snd_nxt;
s->seq     = s->snd_una;
s->snd_nxt = s->snd_una;
tcp_send_raw(s, TCP_PSH | TCP_ACK, rtbuf, chunk);
s->snd_nxt = saved_nxt;   // 手动恢复
s->seq     = saved_seq;

这种"临时改状态再恢复"的方式容易出错，而且没有指数退避。

从零写OS（四十二）：让 busybox 跑起来 —— 符号链接、fork/exec、调度器 cpu_pin bug

Mon, 01 Jun 2026 08:00:00 +0000

上一章实现了 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 的符号链接。

用 tclaw 做了 6 个小游戏

Mon, 01 Jun 2026 00:00:00 +0000

最近在用自己写的 AI 工具 tclaw 做一些实验，让它帮我写了几个纯 HTML 小游戏。

没想到效果挺不错的——贪吃蛇、俄罗斯方块、2048、Flappy Bird、太空侵略者、青蛙过马路，全部跑在浏览器里，不需要安装任何东西。

→ 点这里玩

这几个游戏是通过 tbrain 多 agent 协作完成的：tbrain 负责把任务拆解成子任务，分配给不同的 agent 并行开发，最后汇总结果。整个过程我只提了一句需求，剩下的规划、开发、测试都是 agent 自己跑完的。

所有游戏都是单个 HTML 文件，JS/CSS 全部内联，纯静态，没有服务器逻辑。基本没有人工修改。

有点感慨：以前写这种东西要花好几个小时，现在十几分钟出来六个。

GitHub 开源爬虫与信息订阅工具全览

Tue, 26 May 2026 10:00:00 +0000

想爬数据、订阅信息源、聚合内容？这里整理了 GitHub 上常见的开源爬虫与信息订阅工具，按类别分组，标注了是否需要登录、实现原理、可获取的内容，方便选型。

爬虫框架

项目	语言	实现原理	可爬取内容	是否需要登录	登录方式	Stars	维护状态	部署难度	适用场景
Playwright	TS/Python/Java	控制真实浏览器，完整JS渲染	任意网页内容，含动态渲染（自定义）	❌ 不需要	视目标站而定	89k	活跃	低	JS渲染页面、模拟用户行为、绕过反爬
Scrapy	Python	Twisted异步，XPath/CSS选择器，中间件+Pipeline架构	任意结构化网页数据（自定义）	❌ 不需要	视目标站而定	62k	活跃	中	大规模结构化数据采集
Crawlee	TypeScript	封装Playwright/Puppeteer/Cheerio，内置请求队列+代理轮换	任意网页内容，含SPA（自定义）	❌ 不需要	视目标站而定	23k	活跃	低	Node.js生态爬虫，SPA网站采集

社交媒体爬虫

项目	语言	实现原理	可爬取内容	是否需要登录	登录方式	Stars	维护状态	部署难度	适用场景
MediaCrawler	Python	Playwright控制浏览器，逆向平台API签名，异步并发	帖子/视频标题、正文、图片、视频、点赞/收藏/转发数、评论（含回复）、用户信息、话题标签	⚠️ 部分需要	扫码/Cookie注入	50k	活跃	中	社交媒体内容+评论批量采集、舆情分析
Douyin_TikTok_Download_API	Python	逆向抖音/TikTok API签名算法，FastAPI对外提供接口	视频（无水印）、封面、描述、点赞/评论/分享数、作者信息、音乐信息	⚠️ 部分需要	Cookie注入	18k	活跃	低	视频无水印下载，API集成
dataabc/weibo-crawler	Python	请求微博移动端API，解析JSON，多种存储后端	微博正文、图片、视频、发布时间、点赞/转发/评论数、用户信息、话题	⚠️ 部分需要	Cookie注入	4.5k	较活跃	低	微博用户内容存档
videodl	Python	逆向各平台API获取真实视频地址，FFmpeg合并	视频文件（无水印）、封面图、视频标题	⚠️ 部分需要	Cookie注入	2.1k	一般	低	多平台视频存档
lxSpider	Python	各平台独立实现，含Requests/Selenium/Scrapy多方案	各平台商品/评论/用户/内容数据（视具体案例）	⚠️ 部分需要	各平台不同	2k	一般	低	爬虫学习参考

微信公众号

项目	语言	实现原理	可爬取内容	是否需要登录	登录方式	Stars	维护状态	部署难度	适用场景
WeChatRobot	C++	Windows DLL注入Hook微信进程，访问本地加密数据库	聊天记录、公众号文章、联系人、群组、本地加密数据库	✅ 需要	微信客户端登录（仅Windows）	7.1k	一般	极高	微信数据深度采集、机器人开发
WechatSogou	Python	HTTP请求搜狗微信公开接口，BeautifulSoup解析	公众号名称/简介/头像、文章标题/摘要/链接/发布时间	❌ 不需要	-	6.3k	停止维护	低	公众号内容搜索聚合
wechat_articles_spider	Python	mitmproxy中间人代理拦截微信客户端流量	公众号历史文章全量（标题、正文、发布时间、阅读数、点赞数、原文链接）	✅ 需要	微信客户端登录+抓包	3.4k	一般	高	公众号历史文章全量存档
we-mp-rss	Python	微信账号授权后调用公众号接口，转换RSS输出	公众号文章标题、摘要、正文、发布时间、封面图，转为RSS Feed	✅ 需要	微信账号授权	3.2k	活跃	中	将公众号纳入RSS阅读器统一订阅

新闻爬虫

项目	语言	实现原理	可爬取内容	是否需要登录	登录方式	Stars	维护状态	部署难度	适用场景
newspaper3k	Python	HTTP请求+lxml解析正文，NLP提取摘要/关键词	文章正文、标题、作者、发布时间、摘要、关键词	❌ 不需要	-	15k	停止维护	低	学习参考，生产建议用4k
news-please	Python	Scrapy驱动，自动解析RSS/Sitemap，结构化存储	文章正文、标题、作者、发布时间、描述、图片、语言、来源域名	❌ 不需要	-	2.5k	较活跃	中	大规模新闻数据集构建、学术研究
NewsCrawl	Python	Scrapy+Redis+Celery分布式，定时任务+监控面板	文章标题、正文、发布时间、来源、分类	❌ 不需要	-	671	一般	高	企业级舆情监控
NewsCrawler	Python	Playwright浏览器自动化，覆盖中外媒体	文章标题、正文、发布时间、作者、来源平台	⚠️ 部分需要	Cookie注入	417	活跃	中	中外媒体跨语言新闻聚合
newspaper4k	Python	HTTP请求+lxml解析，NLP提取，支持异步	文章正文、标题、作者、发布时间、摘要、关键词、顶部图片	❌ 不需要	-	1.1k	活跃	低	快速提取任意新闻正文

RSS 阅读器 / 信息聚合

项目	语言	实现原理	可爬取内容	是否需要登录	登录方式	Stars	维护状态	部署难度	适用场景
Glance	Go	单二进制，定时拉取各平台API，无数据库	RSS文章、Reddit帖子、HN热帖、GitHub Release、YouTube视频、天气、股票	❌ 不需要	部分源需API Key	34k	活跃	极低	个人信息看板
FreshRSS	PHP	定时拉取RSS/Atom feed，兼容Google Reader/Fever API	RSS/Atom订阅源的文章标题、正文、发布时间、作者、链接	❌ 不需要	-	15k	活跃	中	自托管RSS服务，多用户共享
Miniflux	Go	轻量HTTP服务+PostgreSQL，定时抓取RSS	RSS/Atom订阅源的文章标题、正文、发布时间、作者、链接、附件	❌ 不需要	-	9.3k	活跃	低	极简高性能RSS，键盘流用户
RSSbrew	Python	拉取RSS后过滤+调用OpenAI生成摘要，输出新Feed	RSS源文章，经过滤/AI摘要后重新输出为新RSS	❌ 不需要	OpenAI API Key	287	较活跃	低	RSS内容过滤与AI摘要提炼

选型建议

爬取国内社交媒体（小红书/抖音/微博/B站）→ MediaCrawler，覆盖最全，维护最活跃
订阅微信公众号 → we-mp-rss 转成 RSS，配合 Miniflux 或 FreshRSS 统一阅读
自建 RSS 服务 → 极简选 Miniflux，功能全选 FreshRSS
个人信息聚合看板 → Glance，一个 Docker 命令搞定
提取任意新闻正文 → newspaper4k，3 行代码搞定
自定义爬虫开发 → Python 用 Scrapy，JS 网站加 Playwright；Node.js 用 Crawlee
下载抖音/TikTok 视频 → Douyin_TikTok_Download_API，有完整 REST API

语音克隆（二）：主流开源项目全景对比

Tue, 26 May 2026 00:00:00 +0000

目前开源语音克隆项目百花齐放，本文整理了 GitHub 上最热门的项目，对比各自的架构、语言支持、适用场景，帮你快速选型。

Stars 排行榜

排名	项目	Stars	核心特点
1	Real-Time-Voice-Cloning	~60k	经典三阶段流水线，最早流行的克隆项目
2	GPT-SoVITS	~58k	中文最强，1分钟数据即可微调
3	Coqui TTS (XTTS)	~45k	工业级框架，17种语言，3秒零样本
4	ChatTTS	~39k	中文对话语音质量领先，支持笑声停顿等
5	Bark	~39k	创意音频，可生成笑声/哭声/背景音效
6	MockingBird	~37k	中文版 Real-Time-Voice-Cloning
7	OpenVoice	~37k	音色迁移架构，推理极快
8	RVC	~36k	歌声转换首选，支持实时变声
9	Fish Speech	~31k	端到端，多语言，工业级质量
10	so-vits-svc	~28k	AI翻唱鼻祖，歌声克隆质量极高
11	Chatterbox	~25k	Resemble AI开源，情感可控
12	CosyVoice	~21k	阿里出品，LLM+流匹配，5种语言
13	Index-TTS	~21k	bilibili出品，工业级稳定
14	F5-TTS	~15k	流匹配，非自回归，推理快
15	OmniVoice	~6.6k	支持600+语言，扩散语言模型

完整对比表

项目	架构	支持语言	零样本克隆	推理速度	需要训练	最适合场景
Real-Time-Voice-Cloning	三阶段流水线	英文	是（5s）	接近实时	否	学习/原型验证
GPT-SoVITS	GPT + VITS	中/英/日	是（可微调）	中等	可选	中文配音首选
Coqui TTS	多架构框架	17种	是（3s）	中等	否	多语言生产部署
Bark	自回归LM	13种	弱	慢	否	创意/情感音频
ChatTTS	生成式LM	中/英	是	中等	否	中文对话TTS
MockingBird	三阶段流水线	中/英	是（5s）	接近实时	否	中文克隆
OpenVoice	音色迁移	6种	是	极快	否	快速克隆部署
RVC	VITS + 特征检索	语言无关	需少量训练	实时	是（<10min）	歌声/实时变声
Fish Speech	端到端AR + VQGAN	8+种	是（10s）	快	否	高质量多语言
so-vits-svc	SoftVC + VITS	语言无关	需训练	中等	是	AI翻唱
Chatterbox	s3gen + 扩散	英文	是	快	否	英语情感配音
CosyVoice	LLM + 流匹配	中/英/日/粤/韩	是（3-10s）	快	否	商业TTS服务
Index-TTS	GPT-style	中/英	是	快	否	工业生产
Tortoise TTS	自回归 + 扩散	英文	是	慢	否	高质量英语有声书
F5-TTS	流匹配 DiT	中/英	是	快	否	快速零样本克隆
StyleTTS2	扩散 + SLM	英文	是	中等	否	英语质量基准
VALL-E-X	神经编解码LM	英/中/日	是	中等	否	跨语言克隆
Kokoro	StyleTTS2变体	英+中日韩法	否（固定音色）	极快	否	本地轻量部署
OmniVoice	扩散语言模型	600+种	是	快	否	超多语言
EmotiVoice	BERT + TTS	中/英	有限	中等	否	情感化中文TTS
VoiceCraft	自回归 + 码书重排	英文	是	中等	否	语音片段编辑
Qwen3-TTS	LLM-native	多语言	是	中等	否	与LLM集成
MetaVoice	自回归 + 扩散(1B)	英文	是（30s）	中等	否	高质量英语克隆
Parler-TTS	描述控制TTS	英文	文本描述控制	中等	否	可控TTS研究
ZipVoice	流匹配 + 蒸馏	中/英	是	极快	否	低延迟实时TTS
ESPnet	多架构工具包	多语言	有	依模型	通常需要	学术研究

按使用场景推荐

中文语音克隆

GPT-SoVITS > ChatTTS > CosyVoice > Index-TTS

语音克隆（一）：用 OmniVoice 克隆任意声音

Mon, 25 May 2026 00:00:00 +0000

想让 AI 用你的声音说话？只需要一段 3 到 10 秒的录音，OmniVoice 就能克隆你的声音，说出任意文字。

OmniVoice 是什么

OmniVoice 是小米 / k2-fsa 团队开发的开源零样本 TTS 模型，支持 600+ 种语言，基于扩散语言模型架构，推理速度极快（RTF 最低 0.025，比实时快 40 倍）。

支持三种模式：

语音克隆：提供参考音频，克隆声音说出任意文字
语音设计：用文字描述声音（性别、年龄、音调、口音等）
自动语音：模型自动选择声音

环境准备

安装 conda 环境

conda create -n omnivoice python=3.11 -y
conda activate omnivoice

安装 PyTorch

# Apple Silicon
pip install torch==2.8.0 torchaudio==2.8.0

# NVIDIA GPU（以 CUDA 12.8 为例）
pip install torch==2.8.0+cu128 torchaudio==2.8.0+cu128 --extra-index-url https://download.pytorch.org/whl/cu128

安装 OmniVoice

git clone https://github.com/k2-fsa/OmniVoice.git
cd OmniVoice
pip install -e .

下载模型

第一次运行会自动下载。如果在国内连不上 HuggingFace，设置镜像：

从零写OS（三十七）：网络栈 —— e1000 驱动 + ARP/IP/TCP + Socket

Fri, 22 May 2026 08:00:00 +0000

文件系统能读写了，这一章加网络支持。目标是实现一个最小 TCP/IP 栈，让用户程序能通过 socket 发送 HTTP 请求并收到响应。

验证方式：

/ # wget_test
wget_test start
connecting...
connected!
request sent
HTTP/1.0 200 OK
...
DONE

架构概览

用户程序（wget_test）
  ↕ syscall: socket/connect/write/read/close
内核 socket 层（net.c）
  ↕ tcp_connect / tcp_send / tcp_recv / tcp_close
TCP 层（net.c）
  ↕ 以太网帧收发
ARP 层（net.c）
  ↕ e1000_send / e1000_recv
e1000 网卡驱动（e1000.c）
  ↕ MMIO + DMA
QEMU e1000 虚拟网卡（-netdev user,id=net0 -device e1000,netdev=net0）

PCI 枚举

e1000 通过 PCI 总线连接。内核在启动时枚举 PCI 设备：

void pci_enumerate(void) {
    for (bus=0; bus<256; bus++)
        for (dev=0; dev<32; dev++)
            for (fn=0; fn<8; fn++) {
                uint16_t vendor = pci_read16(bus, dev, fn, 0);
                if (vendor == 0xFFFF) continue;
                // 记录 vendor/device/bar0
            }
}

e1000 的 vendor=0x8086，device=0x100E。BAR0 是 MMIO 基地址（通常 0xFEBC0000）。

从零写OS（三十六）：ext2 写操作 —— 文件创建、引用计数与 tty 字符设备

Fri, 22 May 2026 07:00:00 +0000

前几章文件系统都是只读的。这一章实现 ext2 的写路径，让 echo hello > /tmp/a.txt && cat /tmp/a.txt 能正常工作，且重启后文件仍然存在。过程中还修了 fd 引用计数和 tty 字符设备两个问题。

ext2 磁盘结构回顾

块组 0:
  [超级块][组描述符][block bitmap][inode bitmap][inode table][数据块...]

关键字段：

sb->s_free_inodes_count / gd->bg_free_inodes_count：空闲 inode 计数
sb->s_free_blocks_count / gd->bg_free_blocks_count：空闲 block 计数
gd->bg_inode_bitmap：inode bitmap 所在块号
gd->bg_block_bitmap：block bitmap 所在块号
gd->bg_inode_table：inode table 起始块号

inode 号从 1 开始；前 10 个是系统保留的（root=2，lost+found=11）。

alloc_inode / alloc_block

alloc_inode

uint32_t alloc_inode(void) {
    // 1. 读 inode bitmap 块
    // 2. 找第一个为 0 的位（bit i → inode i+1）
    // 3. 置位，写回 bitmap
    // 4. 更新超级块和组描述符的 free_inodes_count
    // 5. 返回 inode 号（从 1 开始）
}

alloc_block

uint32_t alloc_block(void) {
    // 1. 读 block bitmap 块
    // 2. 找第一个为 0 的位，跳过 block 0（保留）
    // 3. 置位，写回 bitmap
    // 4. 更新超级块和组描述符的 free_blocks_count
    // 5. 清零新分配的块（避免垃圾数据）
    // 6. 返回块号
}

注意：block bitmap 的 bit 0 对应 block 0，必须跳过（block 0 不存在）。实际第一个可分配的块由文件系统布局决定（本项目中是 610）。

从零写OS（三十五）：getdents64 + chdir + 内存屏障 Bug

Fri, 22 May 2026 06:00:00 +0000

上一章 ls 能运行了，但打印出来的目录内容是空的——因为还没有实现 getdents64。这一章把目录列表、cd、pwd 全部补齐，同时碰到了一个 -O2 下内存乱序导致的调度器死循环 Bug。

SYS_GETDENTS64

Linux 接口

int getdents64(int fd, struct linux_dirent64 *dirp, unsigned int count);

每个条目的结构：

struct linux_dirent64 {
    uint64_t d_ino;       // inode 号
    int64_t  d_off;       // 到下一条目的偏移（可用递增序号代替）
    uint16_t d_reclen;    // 本条目总字节数（含填充，8 字节对齐）
    uint8_t  d_type;      // 文件类型（4=目录，8=普通文件）
    char     d_name[];    // 文件名（null 结尾）
};

d_reclen 必须 8 字节对齐，计算方式：

uint16_t reclen = (uint16_t)((19 + namelen + 1 + 7) & ~7);
//                             ↑固定头部  ↑名字  ↑null  ↑对齐

内核实现

在 VFS 层实现 vfs_getdents，遍历 ext2 目录的所有条目，逐个填写 linux_dirent64 并写入用户缓冲区：

int vfs_getdents(int fd, uint64_t uva, uint32_t count) {
    // 1. 检查 fd 是否为目录
    // 2. 从 offset 开始遍历 ext2 目录
    // 3. 跳过 "." 和 ".."（busybox ls 不显示它们）
    // 4. 每个条目：填 d_ino、d_type、d_name、d_reclen
    // 5. 通过 copy_to_user 写入用户空间
    // 6. 更新 file->offset，返回写入的总字节数
}

关键：返回 0 表示目录已读完（EOF），busybox ls 据此停止调用。

从零写OS（三十四）：阻塞式管道与调度器的两个 Bug

Fri, 22 May 2026 05:00:00 +0000

上一章实现了阻塞式 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

关键点：

从零写OS（三十三）：阻塞式 TTY —— read 不再忙等

Fri, 22 May 2026 04:00:00 +0000

上一章 busybox sh 成功显示了 / # 提示符，但 shell 拿不到任何输入——因为 tty_read 是忙轮询的，没有字符就直接返回 0，shell 以为收到 EOF，立刻退出。这一章实现真正的阻塞式 TTY，让 shell 能等待用户输入。

之前的问题

之前的 tty_read 大概是这样：

int tty_read(char *buf, int len) {
    // 轮询串口状态寄存器
    if (!(inb(0x3F8 + 5) & 1)) return 0;   // 没数据就返回 0
    *buf = inb(0x3F8);
    return 1;
}

这有两个问题：

没有输入时返回 0，上层程序（shell）以为是 EOF
如果上层在循环里调这个，CPU 100% 占用

正确做法：没有输入时挂起进程，等串口中断来了再唤醒。

串口中断（IRQ4）

COM1 对应 IRQ4，接在 PIC 主片的 IR4 引脚。要用串口中断，需要两步：

1. 在 PIC 上 unmask IRQ4：

// PIC 主片 IMR 寄存器：0 表示开放，1 表示屏蔽
uint8_t mask = inb(0x21);
mask &= ~(1 << 4);   // 清除 bit4，开放 IRQ4
outb(0x21, mask);

2. 开启串口的接收中断：

从零写OS（三十二）：启动 busybox sh —— 用户指针与内核页表的陷阱

Fri, 22 May 2026 03:00:00 +0000

ch31 已经能跑 musl libc 的 hello world 了，这一章目标更高：启动 busybox sh，看到 / # 提示符。busybox 是个真正的程序，碰到的问题也更真实。

准备工作

获取静态编译的 busybox

wget https://busybox.net/downloads/binaries/1.35.0-x86_64-linux-musl/busybox
chmod +x busybox
file busybox
# busybox: ELF 64-bit LSB executable, x86-64, statically linked

更新 ext2 镜像

busybox 需要 /bin/sh、/etc/passwd、/etc/group：

sudo mkdir -p /tmp/ext2mnt/bin
sudo mkdir -p /tmp/ext2mnt/etc
sudo cp $(BUSYBOX) /tmp/ext2mnt/bin/busybox
sudo cp $(BUSYBOX) /tmp/ext2mnt/bin/sh
printf 'root:x:0:0:root:/root:/bin/sh\n' | sudo tee /tmp/ext2mnt/etc/passwd > /dev/null
printf 'root:x:0:\n' | sudo tee /tmp/ext2mnt/etc/group > /dev/null

Bug 1：GDT TSS 描述符溢出

x86_64 下 TSS 描述符是 16 字节（两个 qword），GDT 必须为它预留两个连续槽位。之前只预留了一个，导致 TSS 描述符的高 8 字节覆盖了相邻的全局变量（恰好是 mmap_next），进程一分配匿名内存就跳到奇怪的地址。

从零写OS（三十一）：运行 musl libc 程序 —— 两个隐藏的寄存器 Bug

Fri, 22 May 2026 02:00:00 +0000

上一章对齐了 Linux syscall ABI，现在试着跑一个真正用 musl libc 静态编译的 C 程序。目标很简单：

#include <stdio.h>
int main(int argc, char **argv) {
    printf("hello from musl libc!\n");
    printf("argc=%d\n", argc);
    return 0;
}

编译：musl-gcc -static -O2 -o hello.elf hello.c

结果踩了两个隐藏很深的寄存器 bug，花了不少时间才找出来。

新增的 syscall

musl libc 启动时会调用一批 syscall，其中有三个是绕不过的：

syscall	编号	说明
arch_prctl(ARCH_SET_FS, addr)	158	设置 TLS base（FS 寄存器）
set_tid_address(tidptr)	218	设置线程 ID 地址，返回 pid
writev(fd, iov, iovcnt)	20	向量写，musl 的 stdio 用它输出

arch_prctl 需要写 MSR 0xC0000100（FS.base），这是 TLS 的基地址，musl 用来存放线程局部变量：

case SYS_ARCH_PRCTL:
    if (a1 == ARCH_SET_FS) {
        wrmsr(0xC0000100, a2);   // FS.base MSR
        return 0;
    }
    return (uint64_t)(-EINVAL);

writev 需要遍历 iov 数组，把多段数据拼起来写到 tty：

从零写OS（三十）：对齐 Linux syscall ABI，让 musl libc 能跑起来

Fri, 22 May 2026 01:00:00 +0000

musl libc 编译出来的程序会直接用 syscall 指令，传的是 Linux x86-64 标准调用号。我们之前的调用号是自己编的，如果不对齐，musl 程序一个 syscall 都跑不通。这一章把内核的 syscall 接口全面对齐 Linux ABI。

Linux x86-64 syscall 约定

Linux 的 x86-64 syscall 约定：

调用：rax=syscall号，rdi=a1，rsi=a2，rdx=a3，r10=a4，r8=a5，r9=a6
返回：rax（负数表示错误，如 -ENOENT = -2）
CPU 自动保存：rcx=用户 rip，r11=用户 rflags

注意第 4 个参数是 r10，不是 rcx。原因是 syscall 指令会把用户 rip 存进 rcx，所以 r10 顶替了 rcx 的位置。这一点非常容易踩坑。

关键改动

1. syscall 号全部换成 Linux 标准

之前的调用号是自己定义的，现在全部换成 Linux 标准值：

功能	之前	现在
read	6	0
write	1	1 ✓
open	5	2
close	7	3
fork	3	57
exit	2	60
kill	12	62

write 碰巧没变，其他大部分都不一样。

从零写OS（二十九）：block cache —— 给磁盘加一层缓存

Fri, 15 May 2026 02:00:00 +0000

Linux 内核里有个叫 page cache（以前叫 buffer cache）的东西，所有磁盘 IO 都要经过它。为什么？因为磁盘太慢了——ATA PIO 读一个扇区要等几毫秒，而内存访问只要几纳秒。把最近访问过的扇区留在内存里，下次再访问直接从内存读，速度提升几千倍。

这一章给我们的 ext2 文件系统加上这层缓存，同时顺手修了一个隐藏很深的调度器 bug。

设计：LRU write-back 缓存

最简单够用的设计：固定 64 个 slot，每个 slot 缓存一个 512 字节扇区，LRU 淘汰，write-back 写回。

typedef struct {
    uint32_t lba;
    uint8_t  data[512];
    uint8_t  valid;
    uint8_t  dirty;
    uint32_t lru_time;
} bcache_slot_t;

static bcache_slot_t slots[64];
static uint32_t      clock = 0;

lru_time 用一个全局 clock 计数器实现——每次访问 clock++，命中的 slot 拿到最新值，淘汰时找 lru_time 最小的那个。

bcache_get(lba)

uint8_t *bcache_get(uint32_t lba) {
    clock++;

    // 命中？
    for (int i = 0; i < 64; i++) {
        if (slots[i].valid && slots[i].lba == lba) {
            slots[i].lru_time = clock;
            return slots[i].data;
        }
    }

    // 找 LRU victim
    int victim = 0;
    for (int i = 1; i < 64; i++) {
        if (!slots[i].valid) { victim = i; break; }
        if (slots[i].lru_time < slots[victim].lru_time) victim = i;
    }

    // victim 是 dirty 的？先写回磁盘
    if (slots[victim].valid && slots[victim].dirty)
        ata_write_sector(slots[victim].lba, slots[victim].data);

    // 读新扇区
    ata_read_sector(lba, slots[victim].data);
    slots[victim] = (bcache_slot_t){ lba, ..., valid=1, dirty=0, lru_time=clock };
    return slots[victim].data;
}

返回的是指向缓存数据的指针，调用方可以直接读写这块内存。写完后调 bcache_dirty(lba) 标记为脏。

从零写OS（二十八）：timer —— 让进程睡一会儿

Fri, 15 May 2026 01:00:00 +0000

Linux 里的 sleep(2) 背后是什么？

进程调用 sleep，内核把它标记为"阻塞"，让出 CPU 给其他进程，等时间到了再唤醒它。实现这个功能需要两个组件配合：定时器（知道时间到了）+ 调度器（切换进程）。

好消息是这两个我们都有了：PIT 100Hz 时钟 + round-robin 调度器。这一章只需要把它们接起来。

核心思路

SYS_SLEEP(ms)
  → sleep_until = pit_get_ticks() + ms/10
  → state = PROC_BLOCKED

IRQ0 handler（每 10ms）
  → pit_tick()      // ticks++
  → timer_tick()    // 扫描所有进程，到期则唤醒
  → sched_tick()    // 调度下一个 READY 进程

进程睡觉时设好"闹钟"（sleep_until），然后自己进入 PROC_BLOCKED。每次时钟中断，timer_tick 扫一遍所有进程，到期的改回 PROC_READY，下次调度就能运行了。

实现

1. process_t 加一个字段

typedef struct {
    // ... 原有字段
    uint64_t sleep_until;   // 睡到哪个 tick，0 表示没在睡
} process_t;

2. timer.c

void timer_tick(void) {
    uint64_t now = pit_get_ticks();
    for (int i = 0; i < MAX_PROCS; i++) {
        if (procs[i].state == PROC_BLOCKED && procs[i].sleep_until > 0) {
            if (now >= procs[i].sleep_until) {
                procs[i].sleep_until = 0;
                procs[i].state = PROC_READY;
            }
        }
    }
}

逻辑极简：遍历，到期，唤醒。

从零写OS（二十七）：字符设备 —— /dev/null 和 /dev/zero

Thu, 14 May 2026 07:00:00 +0000

Linux 里有个特殊目录 /dev/，里面住着各种设备文件：

/dev/null     ← 写什么扔什么，读永远 EOF
/dev/zero     ← 读出来全是 \0
/dev/random   ← 读出来是随机字节
/dev/tty      ← 当前终端

对用户程序来说，它们和普通文件没区别：open、read、write、close，完全一样的接口。

这一章实现字符设备（char device）框架，让 VFS 能路由 /dev/ 路径，并内置 null 和 zero 两个最基础的设备。

什么是字符设备

字符设备（character device）的特点：

按字节读写，没有块/扇区的概念
没有随机寻址（不像磁盘文件可以 seek）
读写是即时的：写进去就消失（null）或立刻可读（zero/tty）

与之对应的是块设备（block device），如硬盘，以固定大小的块为单位操作。

设备注册表

核心数据结构 cdev_t：

typedef struct {
    char    name[16];              // 设备名，如 "null"、"zero"
    int     (*open) (void);
    int     (*read) (void *buf, uint32_t len);
    int     (*write)(const void *buf, uint32_t len);
    void    (*close)(int fd);
    int     used;
} cdev_t;

static cdev_t devs[CDEV_MAX];     // 全局设备表

通过函数指针实现多态——不同设备注册不同的 read/write 实现。

chardev_register 向 devs[] 添加一个设备，chardev_open 按名字查找并调用 open()。

从零写OS（二十六）：poll —— 同时等待多个 fd

Thu, 14 May 2026 06:00:00 +0000

上一章实现了 TTY 输入，但用户程序只能这样等输入：

.read_loop:
    syscall SYS_READ(fd=0, buf, 64)
    cmp rax, 0
    jle .read_loop

问题很明显：

CPU 全速空转：没有输入时 SYS_READ 每次返回 0，进程白白占用 CPU
无法同时等多个 fd：如果既要等 stdin，又要等 pipe，必须串行轮询，任一 fd 都可能饿死

poll 解决这两个问题。

poll 是什么

poll(fds[], nfds, timeout) 是一个系统调用：

传入一组 pollfd_t 结构，每个描述"我关心 fd X 的什么事件"
内核检查每个 fd 是否满足条件
返回就绪的 fd 数量，并在 revents 里标记哪些事件发生了

struct pollfd {
    int   fd;       // 监听哪个 fd
    short events;   // 关心：POLLIN（可读）/ POLLOUT（可写）
    short revents;  // 内核填写：实际发生了什么
};

int poll(struct pollfd *fds, int nfds, int timeout_ms);

有了 poll，程序可以：

poll([{fd=0, POLLIN}, {fd=pipe_r, POLLIN}], 2, -1)
  → 等到任意一个有数据，才返回

实现架构

整体分四层：

从零写OS（二十五）：TTY 终端输入

Thu, 14 May 2026 05:00:00 +0000

到目前为止，进程只能输出，没有办法接收用户输入。SYS_READ 形同虚设，键盘按了也没反应。

这一章实现 TTY——Unix 对终端设备的最初抽象，让进程能以行为单位从串口读取输入。

TTY 是什么

TTY 原本是 teletypewriter（电传打字机）的缩写。在 Unix 里，它泛指"终端"——一个字符设备，既能接收键盘输入，又能输出文字。

现代 Linux 里的 /dev/tty、/dev/pts/0 都是 TTY 的后代。我们这里用串口 COM1 模拟一个最简单的 TTY。

整体架构

用户键盘输入
   ↓ 串口硬件触发 IRQ4
isr_handler → tty_recv(c)   ← 回显 + 写入 ring buffer
                ↓ 遇到 '\n'
           line_ready = 1
                ↓ 进程 syscall SYS_READ(fd=0)
           tty_read(buf, len)  ← 把一行搬到用户 buf
                ↓
           用户程序处理输入

三个关键组件：

Ring Buffer：固定大小的环形缓冲区，存放还未被读走的字符
行规程（line discipline）：积累字符，遇 \n 才通知"行就绪"
IRQ4 中断处理：从串口读一个字节，交给 TTY

Ring Buffer

环形缓冲区是一个固定数组，加上读指针和写指针：

[ _ _ _ _ h e l l o \n _ _ ]
           ↑                 ↑
         rx_read          rx_write
rx_len = 6

写字符：rx_buf[rx_write] = c; rx_write = (rx_write + 1) % TTY_BUF_SIZE; rx_len++

从零写OS（二十四）：signal 信号机制

Thu, 14 May 2026 04:00:00 +0000

到目前为止，进程只能顺序跑完，没有"被打断"的能力。按 Ctrl+C 没有反应，子进程崩溃父进程不知道，kill 命令更无从谈起。

这一章实现 signal——内核向进程发送异步通知的机制。

信号是什么

信号是一个整数编号，内核用它告诉进程"发生了某件事"：

信号	编号	默认行为
SIGUSR1	10	终止
SIGKILL	9	终止（不可捕获）
SIGTERM	15	终止
SIGCHLD	17	忽略

进程可以用 signal(sig, handler) 注册自定义处理函数，也可以接受默认行为。

关键：信号不立刻打断进程

信号发送时只是设置一个 pending 位，不立刻跳转。等进程下次从内核态返回用户态时，才检查并派发：

SYS_KILL → pending_signals |= (1 << sig)

syscall 处理完 → 准备 sysret
                    ↓
          检查 pending_signals
                    ↓
        有信号 → 操纵 user_rip/user_rsp → sysret 跳到 handler
        handler 执行完 ret → 回到原来被中断的位置

这和硬件中断不同——硬件中断可以在任意时刻打断 CPU，信号只在内核→用户的切换点才生效。

派发机制（trampoline）

signal_dispatch 收到两个指针：内核栈上保存的 user_rip（原来准备 sysret 到的地址）和 user_rsp。它做的事：

1. user_rsp -= 8
2. *(user_rsp) = user_rip    // 原返回地址压到用户栈
3. user_rip = handler_addr   // sysret 改跳到 handler

sysret 跳到 handler，handler 执行完 ret，弹出用户栈上的原 rip，回到 kill syscall 之后继续。

从零写OS（二十三）：procfs 进程文件系统

Thu, 14 May 2026 03:00:00 +0000

上一章有了 pipe 和 fd，现在进程可以互相传数据了。但还有一个问题：用户程序没有办法查询"系统里现在有哪些进程"——这类信息只存在内核里，外面拿不到。

加专用 syscall 当然可以，但 Linux 选择了一个更优雅的方案：procfs。

一切皆文件

procfs 的思路是：把内核状态伪装成文件，挂在 /proc/ 目录下。

/proc/0/status   → 进程 0 的信息
/proc/1/status   → 进程 1 的信息

用户程序用完全一样的 open/read/close 就能读到，不需要学新 API：

int fd = open("/proc/1/status");
read(fd, buf, 128);
// buf 里是 "pid: 1\nstate: running\nparent: 0\n"

这就是 Linux “一切皆文件” 哲学的体现——统一接口，背后实现可以完全不同。

虚拟文件和真实文件的区别

普通文件的 read：从磁盘读数据。

procfs 文件的 read：内核现场生成内容，没有磁盘，没有 inode，数据就是 procs[] 数组里的字段格式化出来的字符串。

open("/proc/1/status")
  → vfs_open 识别 "/proc/" 前缀
  → procfs_open 解析 pid，格式化状态字符串存入内核 buf
  → 返回 VFile（type=VFILE_PROC）

read(fd, buf, len)
  → vfs_read 识别 VFILE_PROC
  → 从内核 buf 按 offset 拷贝给用户

实现

procfs 内核结构

typedef struct {
    int      used;
    uint32_t pid;
    char     buf[256];   // open 时格式化好的字符串
    uint32_t buf_len;
    uint32_t offset;     // 支持分段 read
} proc_fd_t;

open 时一次性生成完整字符串，后续 read 只是按 offset 切片拷贝——和普通文件行为完全一致，可以多次 read。

从零写OS（二十二）：管道 pipe 与 dup2

Thu, 14 May 2026 02:00:00 +0000

上一章实现了文件描述符，进程可以用 open/read/close 访问 ext2 文件。但两个进程之间还没有办法通信。shell pipeline cmd1 | cmd2 的本质是：cmd1 的输出直接流进 cmd2 的输入，中间不落磁盘。

这一章实现 pipe 和 dup2，打通进程间通信的最小路径。

pipe 是什么

pipe 是内核里的一块环形字节缓冲区。系统调用 pipe(fds) 返回两个文件描述符：

fds[0] = 读端    fds[1] = 写端

写进程 → fds[1] → [内核 ring buffer 256字节] → fds[0] → 读进程

和普通文件一样，管道也走 fd → VFS → 底层数据这三层，只不过底层数据不是磁盘，而是内核里的 pipe_t。

dup2 是什么

dup2(oldfd, newfd) 让 newfd 指向和 oldfd 同一个内核文件描述符，如果 newfd 已经打开则先关掉它。

shell pipeline 的核心操作就是 dup2 + exec：

// 子进程（cmd1），stdout → pipe 写端
dup2(fds[1], 1);
close(fds[0]);
close(fds[1]);
exec("cmd1");    // cmd1 以为自己在写 stdout，实际写进了管道

// 父进程（cmd2），stdin → pipe 读端
dup2(fds[0], 0);
close(fds[0]);
close(fds[1]);   // 关掉写端，否则 cmd2 永远等不到 EOF
exec("cmd2");

pipe 的 EOF 语义

read 管道什么时候返回 0（EOF）？

从零写OS（二十一）：文件描述符 fd

Thu, 14 May 2026 01:00:00 +0000

前几章的用户程序如果想读文件，得直接传 inode 号给内核——read(ino, offset, buf, len)。这意味着用户程序要自己记当前读到哪了，而且根本不知道文件名，只有一个数字。

这一章引入 文件描述符（fd），让用户程序用熟悉的方式操作文件：

int fd = open("hello.txt");
int n  = read(fd, buf, 64);
close(fd);

fd 是什么

fd 是一个进程内的整数，通常从 0 开始分配（0=stdin，1=stdout，2=stderr，之后是普通文件）。

它背后有三层：

进程 fd_table[]          内核 open_file             磁盘
  fd=3  ──────────→   { ino=42, offset=0 }  ──→  hello.txt
  fd=4  ──────────→   { ino=43, offset=0 }  ──→  readme.txt

fd 本身只是下标，真正存 offset 的是内核里的"打开文件"结构。这样的好处：

offset 由内核自动推进，用户不用管
fork 后父子可以共享同一个打开文件（共享 offset）
文件、管道、设备用同一套接口，背后实现不同

实现：每个进程一张 fd 表

在 process_t 里加一个数组：

typedef struct {
    // ...
    int32_t fd_table[PROC_MAX_FD];  // fd → vfs_fd，-1 表示空槽
} process_t;

fd_table[fd] 存的是 VFS 层的内部 fd（VFile 数组下标）。

从零写OS（二十）：wait / exit 完整语义

Wed, 13 May 2026 00:00:00 +0000

上一章实现了 exec()，用户程序能跑起来了。但进程退出时只是把进程表项清掉，父进程拿不到退出码，也没有办法等待。这一章实现完整的 exit / wait 语义。

为什么进程退出后不能直接消失

直觉上，进程退出就应该立刻清掉进程表项。但这里有个问题：父进程怎么拿到子进程的退出码？

如果进程表项直接清掉，退出码就丢了。父进程调用 wait() 的时机可能比子进程 exit() 晚，也可能早——无论哪种情况，父进程都需要能读到那个退出码。

Linux 的解法是引入**僵尸（zombie）**状态：进程 exit() 后不立即消失，保留退出码，等父进程 wait() 读取后才彻底释放。

这就是为什么 ps 输出里偶尔会出现状态为 Z 的进程——它已经退出了，只是在等父进程来"收尸"。

进程状态机的变化

原来进程只有三个状态：UNUSED、READY、RUNNING。这一章加两个：

UNUSED → READY → RUNNING
                    ↓ exit()
                 ZOMBIE   ← 已退出，等父进程 wait
                    ↑ 唤醒
                 BLOCKED  ← 父进程 wait 时挂起

调度器只挑 READY 的进程运行，ZOMBIE 和 BLOCKED 自然就不会被调度到，不需要改调度器的逻辑。

exit 和 wait 的实现思路

exit 做三件事：

把退出码存到进程表项，状态改为 ZOMBIE
如果父进程正在 BLOCKED 等待，把它改回 READY（唤醒）
切回内核栈和内核页表，hlt 循环等待被回收

wait 做的事：

扫描进程表，找有没有自己的子进程且状态是 ZOMBIE
找到了：读退出码，把它设为 UNUSED，返回退出码
没找到但有活着的子进程：挂起等待（ring3）或返回 -2 让调用方重试（ring0）
没有子进程：返回 -1

parent_pid 需要在 exec / fork 时记下来，这样 exit 才知道该唤醒谁，wait 才知道哪些进程是自己的子进程。

从零写OS（十九）：exec 与用户程序

Sat, 09 May 2026 00:00:00 +0000

之前所有代码都跑在内核态（ring0）。这一章第一次让用户程序在 ring3 里运行——加载 ELF 文件，跳到用户态执行，用户程序通过 syscall 和内核通信。

这是操作系统最核心的一个边界：内核和用户程序之间的隔离。

exec 做什么

exec 的语义是"用一个新程序替换当前进程"：

从文件系统读 ELF 文件
解析 ELF header，找到各个段的加载地址
创建新的用户页表，把各段加载进去
分配用户栈
设置进程的 rip = 入口地址，rsp = 栈顶，cs/ss = 用户段，放入就绪队列

调度器下次选中这个进程，就会跳到用户态开始执行。

进入用户态：iretq

第一次进入用户态不能用 sysret——没有对应的 syscall。用 iretq：

static void enter_usermode(uint64_t rip, uint64_t cs,
                            uint64_t rflags, uint64_t rsp, uint64_t ss) {
    __asm__ volatile(
        "push %4\n"   // ss
        "push %3\n"   // rsp
        "push %2\n"   // rflags（IF=1，开中断）
        "push %1\n"   // cs（0x23，ring3 代码段）
        "push %0\n"   // rip（entry point）
        "iretq"
        :: "r"(rip), "r"(cs), "r"(rflags), "r"(rsp), "r"(ss)
    );
}

iretq 弹出这 5 个字段，CPU 检查 cs 的 RPL 发现是 ring3，自动完成特权级切换。

从零写OS（十八）：fork 与 Copy-on-Write

Fri, 08 May 2026 00:00:00 +0000

上一章每个进程有了自己的地址空间。这一章实现 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 形同虚设。

从零写OS（十七）：每个进程有自己的地址空间

Thu, 07 May 2026 00:00:00 +0000

前几章的进程共享同一张页表——所有进程看到的是同一片内存。这意味着进程 A 知道进程 B 的地址，就能直接读写它的数据。一个 bug 就能破坏整个系统。

这一章解决这个问题：给每个进程一张自己的页表，互相看不见彼此的内存。

切换页表就是切换世界

x86-64 的虚拟地址翻译规则写在页表里，页表的根地址放在 CR3 寄存器里。

这意味着：写 CR3 就是切换地址空间。进程 A 跑的时候 CR3 指向 A 的页表，进程 B 跑的时候 CR3 指向 B 的页表。同一个虚拟地址 0x400000，在 A 里翻译到物理页 X，在 B 里翻译到物理页 Y——两边完全隔离，互不干扰。

切换进程时，只需要一行：

void vmm_switch(uint64_t *pml4) {
    __asm__ volatile ("mov %0, %%cr3" :: "r"((uint64_t)pml4) : "memory");
}

硬件帮我们做了全部翻译工作。

创建新页表

每个进程需要自己的 PML4。但不能从空白开始——内核代码的映射必须保留，否则切过去之后 CPU 取不到内核指令，立刻 Page Fault。

做法：把内核的 kernel_pml4 整张复制一份作为起点，然后再往里加用户空间的映射。

uint64_t *vmm_create_page_table() {
    uint64_t *new_pml4 = (uint64_t *)pmm_alloc();
    for (int i = 0; i < 512; i++)
        new_pml4[i] = kernel_pml4[i];  // 继承内核映射
    return new_pml4;
}

往指定页表里建映射

之前的 map_page 只能操作当前 CR3 指向的页表。现在需要给进程建映射，但不想先切换过去，所以新接口接受一个显式的 pml4 参数：

从零写OS（十六）：ELF 加载器，运行第一个用户程序

Wed, 06 May 2026 16:00:00 +0000

这一章做完，我们的系统就有了完整的用户程序执行链路：写一个独立的程序，编译成 ELF，放到磁盘上，Shell 里输入 run hello.elf，内核加载并执行它。

ELF 是什么

ELF（Executable and Linkable Format）是 Linux 可执行文件的格式。你编译出来的每个程序、/bin/ls、/usr/bin/python 都是 ELF 文件。

结构很简单：

ELF Header        → 魔数、架构、入口地址
Program Headers   → 每个段加载到内存哪里、从文件哪里读
.text             → 代码
.data             → 数据
.bss              → 未初始化数据（文件里不占空间，加载时清零）

加载一个 ELF，本质上就是：按 Program Header 的指示，把文件里的数据复制到内存里，然后跳到入口地址。

先写用户程序

用户程序不能调内核函数，只能通过 syscall 和内核通信：

BITS 64
section .text
global _start

_start:
    mov rax, 1              ; syscall 1 = print
    lea rdi, [rel msg]      ; RIP 相对寻址
    syscall

    mov rax, 2              ; syscall 2 = exit
    syscall

section .data
msg: db "Hello from ELF!", 13, 10, 0

链接时指定加载地址 0x400000（避开内核占用的低地址区域）：

ENTRY(_start)
SECTIONS {
    . = 0x400000;
    .text : { *(.text) }
    .data : { *(.data) }
}

ELF 加载器

加载流程：

从零写OS（十五）：挂载 ext2，读真实文件系统

Wed, 06 May 2026 15:00:00 +0000

前几章的文件系统是存在内存里的——重启数据就没了，文件名也是硬编码的。这一章做真实的：挂载一个 ext2 磁盘镜像，让 Shell 能读取里面的文件。

上一章已经有了 ATA 驱动，能按扇区号读磁盘。现在的问题是：磁盘上的数据是怎么组织的？

ext2 的结构

ext2 是 Linux 最经典的文件系统，ext3/ext4 都是在它基础上演化来的。理解 ext2，基本上就理解了现代文件系统的核心思路。

磁盘从偏移 1024 字节开始是 Superblock，存整个文件系统的基本参数：block 大小是多少、有多少 inode、magic number 是 0xEF53（用来确认这确实是 ext2）。

接下来是 Group Descriptor，告诉你 inode table 在哪个 block。

然后才是真正的数据区：inode table 和数据块。

Inode 是文件的"身份证"。每个文件有一个唯一的 inode 号，inode 里存着文件大小、权限，以及最重要的——i_block[0..11]，12 个直接指向数据块的指针。想读文件内容，就顺着这些指针去读对应的数据块。

目录也是文件，它的数据块里存的是一条条 ext2_dir_entry：每条记录包含 inode 号、文件名长度、文件名。ls 就是读根目录的数据块，遍历这些记录。

读文件的完整路径

Superblock  → 拿到 block_size、inodes_per_group
GroupDesc   → 拿到 inode table 的起始 block 号
Inode[ino]  → 拿到文件大小和 i_block[]
DataBlock   → 真正的文件内容

读目录（ls）就在最后一步多做一件事：把数据块里的 ext2_dir_entry 链遍历一遍。

每一步都需要从磁盘读若干个扇区——这正是上一章 ATA 驱动的用武之地。

从零写OS（十四）：ATA 驱动，让内核能读磁盘

Wed, 06 May 2026 14:00:00 +0000

前面的文件系统都是存在内存里的——重启数据就没了。要读真实磁盘，得先搞清楚操作系统怎么和磁盘"说话"。这一章做 ATA 磁盘驱动。

磁盘和内核怎么通信

硬盘插在主板上，操作系统通过 ATA 协议和它通信。ATA 协议规定了一组固定的 x86 I/O 端口，内核用 in/out 指令直接操作这些端口，就能控制磁盘。

这叫 PIO 模式（Programmed I/O）——CPU 亲自一个字搬一个字地读数据。慢，但实现只需要几十行代码，是学习的最佳起点。

真实生产内核用 DMA（磁盘直接写内存，CPU 不搬数据），那是后话。

磁盘的最小单位：扇区

磁盘被切成 512 字节的扇区，每个扇区有一个编号，叫 LBA（Logical Block Address），从 0 开始数。

LBA=0 → 前 512 字节（Boot Sector）
LBA=1 → 512~1023 字节
LBA=2 → 1024~1535 字节（ext2 Superblock 就在这里）
...

要读文件系统里偏移 1024 字节的内容，就是读 LBA = 1024 / 512 = 2。

ATA 端口

ATA 协议设计于 1980 年代，把控制磁盘的所有操作映射到一组固定的 I/O 端口号上——这是当时 PC 硬件的惯例，如今这些端口号已经写死在无数设备里，成了不能改的"历史遗产"。

Primary ATA 控制器的端口：

端口	用途
`0x1F0`	数据（读写 16-bit）
`0x1F2`	要读几个扇区
`0x1F3`	LBA[7:0]
`0x1F4`	LBA[15:8]
`0x1F5`	LBA[23:16]
`0x1F6`	选盘 + LBA[27:24]
`0x1F7`	命令（写）/ 状态（读）

状态寄存器的两个关键位：

从零写OS（十三）：Shell，把所有东西串起来

Wed, 06 May 2026 13:00:00 +0000

前十二章，内核从一个 512 字节的 Bootloader 长成了有进程调度、文件系统、VFS 的微型系统。但用户还没有办法和它交互。

这一章做 Shell——一个可以敲命令操作文件的命令行。

先把概念搞清楚

Shell 是普通进程

Shell 不是内核的一部分。它是一个运行在用户态的普通进程，通过系统调用和内核打交道，和 ls、cat 这些程序的地位完全一样。

真实系统里，Shell 用 fork + exec 启动外部命令。我们这里简化：四条命令直接内嵌在 Shell 进程里，不做 fork/exec。

tokenize：命令行的第一步

用户输入一行字符串，Shell 要把它拆成命令名和参数：

"write hello.txt world"
        ↓ tokenize
argv[0] = "write"
argv[1] = "hello.txt"
argv[2] = "world"

做法是遍历字符串，遇到空格就写入 \0 截断，记录每段的起始地址。不需要任何库函数，20 行搞定。

串口 I/O

键盘输入通过串口读取（x86 端口 0x3F8）。QEMU 的 -serial mon:stdio 把宿主机终端直接映射到串口，你在终端敲的每个字符都会被 in 指令读到。

实现了什么

四条命令：

命令	功能
`write <文件> <内容>`	创建文件并写入内容
`read <文件>`	读取文件内容并打印
`ls`	列出根目录所有文件
`help`	打印帮助

关键代码

readline：读一行，支持 backspace

static int readline(char *buf, int maxlen) {
    int i = 0;
    while (i < maxlen - 1) {
        char c = serial_getchar();
        if (c == '\r' || c == '\n') {
            serial_print("\r\n");
            break;
        }
        if (c == 127 || c == '\b') {
            if (i > 0) { i--; serial_print("\b \b"); }
            continue;
        }
        buf[i++] = c;
        char echo[2] = {c, 0};
        serial_print(echo);   // 回显给用户
    }
    buf[i] = '\0';
    return i;
}

\b \b 是终端删除字符的标准做法：退格、打空格覆盖、再退格。

从零写OS（十二）：VFS，让系统调用不认识具体文件系统

Wed, 06 May 2026 12:00:00 +0000

上一章我们写了一个 SimpleFS，可以创建文件、读写内容。但现在有个问题：open() 系统调用直接调的是 fs_create、fs_read 这些 SimpleFS 专属函数。

如果哪天要支持 FAT32，就得去改系统调用的代码。这显然不对。

这一章加一层 VFS（Virtual File System，虚拟文件系统），把系统调用和具体文件系统隔开。

先把概念搞清楚

间接层解耦

软件里有句老话：任何问题都可以通过加一层间接层解决。VFS 就是这层间接层。

用户进程
   ↓  open / read / write
  VFS（统一接口）
   ↓              ↓
SimpleFS         FAT32

系统调用只跟 VFS 说话，VFS 再转发给具体 FS。新增一种文件系统，只需要实现 VFS 要求的那几个函数，不动系统调用层。

file_operations：C 语言的多态

VFS 要求每种文件系统提供一张函数指针表：

typedef struct {
    int (*read) (...);
    int (*write)(...);
    uint32_t (*lookup)(...);
    uint32_t (*create)(...);
} FileOps;

VFS 调 fops->read(...) 时，实际执行的是哪个函数，取决于挂载时注册的是哪张表。这是 C 语言实现"多态"的标准手法，Linux 内核里到处都是这个模式。

vnode：VFS 的通用 inode

具体 FS 有自己的 inode，VFS 层包一层 vnode，里面放着具体 FS 的 inode 号和对应的函数指针表。对上层完全屏蔽了底层差异。

从零写OS（十一）：文件系统，从磁盘到文件名

Wed, 06 May 2026 11:00:00 +0000

到目前为止，内核能跑进程、能做系统调用，但所有数据都在内存里——进程一死，什么都没了。

这一章做文件系统：把数据写到"磁盘"（我们用内存模拟），下次还能读回来。

先把概念搞清楚

动手之前，先理解五件事。

为什么需要文件系统

磁盘本质上就是一个大字节数组。没有文件系统，你只能说"读第 1234 字节"，没法说"读 /etc/passwd"。

文件系统做的事就是在这个字节数组上建立一套命名和组织规则，让你可以用路径找到数据，而不是手动记偏移量。

inode：文件名和内容分离

Unix 最重要的设计之一：inode 描述文件内容，目录存文件名，两者分开。

inode 记录的是"这个文件是什么"——大小、权限、数据在磁盘哪几块——但不存文件名。文件名只是一个指向 inode 的标签，存在目录里。

这意味着同一个 inode 可以被多个名字指向，这就是硬链接。重命名文件也不需要移动任何数据，只改目录项。

超级块：文件系统的自我描述

挂载一块磁盘时，内核第一件事是读超级块。超级块告诉内核这个文件系统的结构：inode 区从哪里开始、数据块从哪里开始、总共多少块、还有多少空闲。

超级块损坏 = 整个文件系统不可读。所以 ext4 会在磁盘多个位置备份超级块。

目录是普通文件

目录没有什么神奇的内部结构，它就是一个普通文件，内容是一张表：文件名 → inode 号。

ls 的本质是读这张表然后打印。路径解析 /a/b/c 就是：读根目录找 a 的 inode → 把 a 当目录读，找 b 的 inode → 把 b 当目录读，找 c 的 inode。

空闲管理：位图

磁盘上哪些块被占用、哪些空闲，用位图记录——1 个 bit 对应 1 个块，0 表示空闲，1 表示已用。分配空间就是找第一个 0 位翻成 1。

这五个概念搞清楚，下面的代码就是它们的直接翻译。

文件系统解决什么问题

内存是易失的，文件系统负责两件事：

从零写OS（十）：系统调用，用户和内核的边界

Wed, 06 May 2026 10:00:00 +0000

前几章的"进程"其实是假的——它们直接跑在内核态，和内核同等权限，可以随意读写任何内存、操作任何硬件。

真实的操作系统里，用户程序跑在用户态（Ring 3），权限受限，不能直接操作硬件。需要内核帮忙时，必须通过系统调用这扇受控的门进入内核，做完事再回去。

这一章实现 syscall / sysret：用户态和内核态之间最快速的切换机制。

两种特权级

x86-64 有 4 个特权级（Ring 0～3），操作系统只用两个：

Ring 0（内核态）：可以执行任何指令，访问任何地址，操作 CR3、MSR 等特权寄存器
Ring 3（用户态）：不能执行特权指令，访问不属于自己的内存会触发 #GP 或 Page Fault

CS 段寄存器的低 2 位（CPL，Current Privilege Level）表示当前特权级。syscall 指令把 CPL 从 3 切到 0，sysret 把 CPL 从 0 切回 3。

为什么用 syscall 而不是中断

早期 Linux 用 int 0x80 触发系统调用——软件中断，要保存完整的中断栈帧，走 IDT 查表，开销大。

syscall / sysret 是专门为系统调用设计的快速路径：不走 IDT，入口地址直接写在 MSR 里，省去了大量压栈操作。现代 x86-64 系统全部用这对指令。

配置 MSR

MSR（Model Specific Register，型号特定寄存器，CPU 内部的一组控制寄存器，用 rdmsr / wrmsr 访问）控制 syscall 的行为。需要配置 4 个：

从零写OS（九）：进程调度，CPU 的分时复用

Wed, 06 May 2026 09:00:00 +0000

到目前为止，内核一直是单线程跑到底——一件事没做完，别的什么都不能干。

这一章让内核同时跑多个进程。每隔一段时间，时钟中断打断当前进程，把 CPU 交给下一个，轮流执行。这就是多任务的核心机制。

上下文是什么

进程被打断之后，下次恢复时要从断点继续执行，不能出错。这意味着必须把 CPU 的状态完整保存下来——这份状态就叫上下文（Context）。

x86-64 ABI 规定了 callee-saved 寄存器（被调用者负责保存的寄存器，C 函数调用约定中，这些寄存器的值在函数调用前后必须保持不变）：rbx、rbp、r12~r15。加上程序指针 rip 和栈指针 rsp，这些就是切换时需要保存和恢复的全部。

typedef struct {
    uint64_t r15, r14, r13, r12;
    uint64_t rbx, rbp;
    uint64_t rip;   // 下次从哪里继续执行
    uint64_t rsp;   // 栈在哪里
} context_t;

每个进程一份 context，切换时：把当前进程的寄存器存入 ctx，再把下一个进程 ctx 里的值写回寄存器——CPU 就"变身"成另一个进程了。

进程结构

#define MAX_PROCS  8
#define STACK_SIZE 8192   // 每个进程 8KB 内核栈

typedef enum {
    PROC_UNUSED = 0,
    PROC_READY,
    PROC_RUNNING,
} proc_state_t;

typedef struct {
    context_t    ctx;
    uint8_t     *stack;
    proc_state_t state;
    uint32_t     pid;
} process_t;

static process_t procs[MAX_PROCS];
static int current_proc = 0;

状态机很简单：UNUSED（槽位空闲）→ READY（等待调度）→ RUNNING（正在跑）→ 被打断后回到 READY。

从零写OS（八）：堆分配器，内核的 malloc

Wed, 06 May 2026 08:00:00 +0000

PMM 负责整页分配，每次给你 4KB。但内核里经常需要分配几十、几百字节的小块——存一个结构体、一条字符串。每次都要一整页，太浪费。

这一章实现 kmalloc / kfree：按需分配任意大小的内存块，用完归还，可以复用。

设计：空闲链表

最经典的堆实现：空闲链表（Free List）。

在堆空间里，每块内存前面加一个块头（header）记录元数据，所有块串成双向链表：

typedef struct block {
    uint64_t      size;     // 这块数据区的大小（不含 header 本身）
    uint8_t       is_free;  // 1=空闲，0=已分配
    struct block *next;     // 链表后继
    struct block *prev;     // 链表前驱
} block_t;

内存布局长这样：

[block_t header | ← size → 数据区 ][block_t header | ← size → 数据区 ] ...
 ↑                                   ↑
 kmalloc 返回这个指针之前的地址        下一块 header

kmalloc 返回的指针指向数据区起始，而不是 header。kfree 时把指针往前偏移 sizeof(block_t)，找回 header，再改 is_free = 1。

堆在哪里

堆从虚拟地址 0x30000 开始，链表头指针存在 0x29000（一个固定位置，方便任何地方都能找到它）：

#define HEAP_START      0x30000ULL
#define HEAP_HEAD_ADDR  0x29000ULL
#define heap_head  (*(block_t **)HEAP_HEAD_ADDR)

初始化时预先映射 4 页（16KB）作为起始堆空间，不够了再动态扩展。

从零写OS（七）：虚拟内存，给每个程序一个假的地址空间

Wed, 06 May 2026 07:00:00 +0000

上一章内核能分配物理页了，但用的全是物理地址。

物理地址有个问题：全局唯一，谁都能访问。进程 A 如果知道进程 B 的物理地址，直接就能读写它的数据。这不行。

解决方案是虚拟内存：每个程序看到的地址都是"假的"，CPU 访问时由硬件自动翻译成真实的物理地址。程序互相隔离，谁也看不见谁。

地址翻译的硬件机制：四级页表

x86-64 的地址翻译靠 MMU（Memory Management Unit，内存管理单元，CPU 内部硬件，负责把虚拟地址翻译成物理地址）完成，翻译规则写在页表里，页表的根地址放在 CR3 寄存器里。

一个 64 位虚拟地址被这样拆开：

63        48 47    39 38    30 29    21 20    12 11       0
[  符号扩展  | PML4_IDX | PDPT_IDX | PD_IDX | PT_IDX | 页内偏移 ]
               9 bit      9 bit      9 bit    9 bit    12 bit

翻译过程是四级查表：

CR3 → PML4[PML4_IDX] → PDPT[PDPT_IDX] → PD[PD_IDX] → PT[PT_IDX] → 物理页帧

每级页表是一个 512 项的数组，每项 8 字节，刚好占满一个 4KB 页。每项的低 12 位是 flags，高位是下一级页表（或最终物理页）的地址。

从零写OS（六）：内存管理，知道自己有多少地可种

Wed, 06 May 2026 06:00:00 +0000

内核跑起来之后，第一个绕不开的问题就是内存。

你不知道这台机器有多少内存，哪些地址段可以用，哪些是硬件保留的。如果随便往一个地址写数据，轻则数据损坏，重则触发异常直接重启。

这一章解决一件事：让内核知道内存的全貌，然后有序地分配和回收物理页。

先问 BIOS：你有多少内存？

我们用 E820（BIOS INT 0x15 AX=E820h，一种标准接口，用来查询物理内存的分布和类型）来探测内存。

这事必须在实模式下做——切换到长模式之后就再也访问不到 BIOS 服务了。所以探测代码放在 boot.asm 里，在进入长模式之前完成。

每次调用 INT 0x15，BIOS 填一条 24 字节的记录：

base    (8字节) — 这段内存的起始物理地址
length  (8字节) — 这段内存的长度（字节）
type    (4字节) — 类型：1=可用，2=保留，其它=别动
ACPI    (4字节) — 扩展属性，一般忽略

循环调用直到 EBX 变成 0，表示枚举完毕。所有记录写入固定地址 0x8000，第一个 4 字节存条目数量。

mov di, MMAP_ADDR + 4   ; 从 0x8004 开始存条目
xor ebx, ebx
xor bp, bp              ; bp 记条目数量
.e820_loop:
    mov eax, 0xE820
    mov ecx, 24
    mov edx, 0x534D4150  ; "SMAP" 魔数，BIOS 验证用
    int 0x15
    jc .e820_done        ; CF=1 表示出错或结束
    inc bp
    add di, 24
    test ebx, ebx
    jz .e820_done        ; ebx=0 表示最后一条
    jmp .e820_loop
.e820_done:
    mov dword [MMAP_ADDR], ebp  ; 把条目数量写到 0x8000

QEMU 上跑出来的内存地图一般长这样：

从零写OS（五）：中断，内核的神经系统

Wed, 06 May 2026 05:00:00 +0000

键盘按下一个键，CPU 是怎么知道的？

不是轮询——CPU 不会没事一直问"键盘有没有按键"。而是靠中断（Interrupt，硬件或软件触发的信号，让 CPU 暂停当前任务去处理紧急事件）。发生了什么事，硬件主动通知 CPU，CPU 暂停手头的事，跳去处理，处理完再回来。

这一章要让内核有能力响应中断。没有这个机制，内核什么都干不了。

中断的分类

x86 的 256 个中断号分三段：

范围	类型	例子
0～31	CPU 异常	除零、缺页、非法指令
32～47	硬件中断	时钟、键盘
48～255	软件中断	系统调用

CPU 异常是 CPU 自己触发的，比如访问了不该访问的内存，CPU 就抛一个缺页异常（Page Fault，访问未映射的虚拟地址时 CPU 触发的异常，操作系统据此做内存按需分配）。

硬件中断是外设触发的，经过 PIC（Programmable Interrupt Controller，可编程中断控制器，负责管理外设中断请求并转发给 CPU）发给 CPU。

IDT：中断的路由表

要处理中断，首先要告诉 CPU：每种中断发生时，去哪个函数处理？

这张路由表叫 IDT（Interrupt Descriptor Table，中断描述符表，256 项，每项对应一个中断号及其处理函数地址）。跟之前的 GDT 一样，是内存里的一张表，用 lidt 指令告诉 CPU 位置。

每个表项里存的是处理函数的地址，还有权限信息。CPU 一旦收到中断，就查这张表，跳到对应函数去执行。

中断处理的细节

CPU 进入中断处理函数之前，会自动把当前的执行状态压栈：rip（下一条指令地址）、cs、rflags、rsp、ss。处理完之后用 iretq（64 位中断返回指令）恢复状态，接着跑。

有一个坑：某些异常 CPU 会自动压入错误码（比如缺页异常），某些不会（比如除零）。为了让处理函数收到的栈结构一致，对没有错误码的异常，要手动压一个 0 占位。这件事用汇编宏做，每种异常一行，干净利落。

第一个测试：故意除以零

IDT 装好之后，最简单的验证方式是故意触发一个异常，看内核能不能捕获到：

从零写OS（四）：汇编交棒给 C，最关键的一跳

Wed, 06 May 2026 04:00:00 +0000

前三章全是汇编。到这里，CPU 已经跑在 64 位长模式下了，但还是什么都做不了。

这一章要完成最关键的一步：把控制权从汇编交给 C。之后的内核全部用 C 写，汇编只在最必要的地方出现。

磁盘要怎么布局

512 字节的 Bootloader 放不下 C 内核，所以内核单独编译成一个二进制文件，放在磁盘的后续扇区（扇区，Sector，磁盘读写的最小单位，传统上每个 512 字节）：

扇区 0（512B）：Bootloader
扇区 1～8     ：内核二进制

Bootloader 启动后，用 BIOS 的磁盘读取中断把扇区 1 开始的内容读到内存地址 0x10000，然后跳过去执行。

一个容易踩的坑：内核入口不在 0x10000

把内核编译好、加载到 0x10000，然后 call 0x10000——看起来没问题，实际上很可能直接崩。

用 objdump（反汇编工具，可以查看二进制文件的结构和函数地址）一查才发现：kernel_main 的实际地址是 0x10109，不是 0x10000。0x10000 开头是另一个函数 outb，跳过去执行完全是错的。

解决方案：加一个 entry.asm 作为内核最开头，内容只有一行：跳转到 kernel_main。然后在链接脚本（Linker Script，告诉链接器如何拼装各个目标文件、每段放在哪个地址）里把 entry.o 排在最前面，保证 _start 恰好落在 0x10000。

这样 Bootloader 跳到 0x10000，第一条指令就是 jmp kernel_main，稳了。

还有一个坑：栈

进入 64 位模式之后，rsp（栈顶指针寄存器）是未初始化的。C 函数一用栈就崩。

在跳入内核之前，要先设好栈：

mov rsp, 0x90000

选 0x90000 是因为这块内存没有被占用，往下增长也不会覆盖内核代码。

内核编译参数

内核不能用普通方式编译，要加几个关键选项：

从零写OS（三）：进入 64 位，CPU 真正醒了

Wed, 06 May 2026 03:00:00 +0000

上一章切到了保护模式，32 位，最多 4GB 内存。

听起来挺多，但现代系统动不动就几十 GB 内存，4GB 根本不够用。所以还得再往前走一步：进入长模式（Long Mode，x86_64 的 64 位工作模式，支持 128TB 虚拟地址空间）。

现在跑在你电脑上的 Linux、macOS、Windows，全都在长模式里。

长模式比保护模式多了什么

最直接的：寻址空间从 4GB 扩展到理论上的 16EB（16 × 10¹⁸ 字节），实际当前 CPU 支持 128TB，够用很久了。

但更重要的变化是强制引入了分页（Paging，把物理内存切成固定大小的页，通过页表做虚拟地址到物理地址的映射）。

保护模式下分页是可选的，长模式下分页是必须开启的。没有页表，CPU 根本不让你进长模式。

先建页表

切换之前，必须在内存里建好页表（Page Table，记录虚拟地址到物理地址映射关系的数据结构）。

x86_64 用四级页表，一个虚拟地址的翻译路径是：

虚拟地址 → PML4 → PDPT → PD → PT → 物理地址

每级都是一张表，每张表 512 项，每项 8 字节。

启动阶段不需要映射所有内存，先映射前 2MB 就够了——把四张表放在物理地址 0x1000 开始的位置，让虚拟地址和物理地址一一对应（恒等映射，虚拟地址和物理地址相同，是启动阶段最简单的映射策略）。

切换步骤

在 32 位保护模式下，按顺序操作：

建好页表，把 PML4 地址写入 CR3（页表根寄存器）
开启 PAE（Physical Address Extension，物理地址扩展，让 32 位系统支持超过 4GB 的物理地址，长模式必须开启）：CR4.PAE=1
设置 EFER.LME=1（通过 MSR 寄存器（Model Specific Register，CPU 内部的特殊寄存器，用 rdmsr/wrmsr 读写）开启长模式使能位）
开启分页：CR0.PG=1，CPU 正式进入长模式兼容态
far jump 跳入 64 位代码段，彻底进入 64 位模式

顺序不能乱。尤其是第 3 步必须在开启分页之前，不然 CPU 会拒绝。

从零写OS（二）：跨过这道门，CPU 才算醒了

Wed, 06 May 2026 02:00:00 +0000

上一章我们让机器打出了第一行字。但那时候 CPU 还处于一种"出厂状态"——实模式，最多只能用 1MB 内存，没有任何权限隔离，任何代码想写哪块内存就写哪块。

这对一个操作系统来说是不可接受的。

所以这一章要做一件事：把 CPU 从实模式切换到保护模式（Protected Mode，32 位工作模式，支持内存保护和权限隔离）。

为什么叫"保护"模式

名字来源很直接——这个模式下，内存是被保护的。

实模式里，程序可以随意读写任何内存地址，一个 bug 就能把整个系统搞崩。保护模式引入了两个机制：

内存段的权限描述：每块内存都有自己的访问权限，越界访问直接触发异常
特权级别（Ring）：内核跑在 Ring 0，用户程序跑在 Ring 3，用户程序没法直接碰内核内存

现代操作系统全都建立在保护模式之上。

切换的关键：GDT

切到保护模式之前，必须先准备好 GDT（Global Descriptor Table，全局描述符表，内存里的一张表，描述每个内存段的地址、大小和权限）。

可以把 GDT 理解成一个"内存段登记簿"。CPU 进入保护模式后，所有内存访问都要查这张表，看看你有没有权限。

GDT 最少需要三项：

索引	用途
0	空描述符（CPU 规定必须全零，不能用）
1	代码段（可执行，Ring 0）
2	数据段（可读写，Ring 0）

GDT 写好之后，用 lgdt 指令告诉 CPU 表在哪里，CPU 才知道去哪查。

切换步骤

整个切换过程就四步，缺一不可：

关中断（cli）—— 切换过程不能被打断，否则 CPU 状态会乱
加载 GDT（lgdt）—— 告诉 CPU 描述符表在哪
设置 CR0 寄存器（CR0.PE=1）—— CR0（控制寄存器0，控制CPU工作模式的关键寄存器）第0位置1，CPU 正式进入保护模式
far jump 刷新流水线 —— 跳转的同时加载新的代码段选择子，清空 CPU 的指令预取缓存

最后这一步很容易漏掉。CPU 有指令流水线，切换模式后如果不强制刷新，可能还在用旧模式的指令译码方式，导致莫名其妙的错误。

从零写OS（一）：让机器听你的第一句话

Wed, 06 May 2026 01:00:00 +0000

电脑开机之后，CPU 做的第一件事是什么？

不是运行 Linux，不是加载驱动，甚至不是执行你写的任何代码——而是执行一段固化在主板上的程序：BIOS（Basic Input/Output System，主板上的固件，负责硬件自检和引导启动）。

BIOS 做完硬件自检之后，会去找一个可以启动的磁盘。找到之后，它做了一件很朴素的事：把磁盘最开头的 512 字节复制到内存地址 0x7C00，然后跳过去执行。

就这样。没有操作系统，没有文件系统，没有任何框架。你写的代码，就从这 512 字节开始。

512 字节能干什么

说实话，不多。但够用来在屏幕上打一行字。

这一章的目标很简单：从磁盘启动，打印 Hello, OS!。

这段代码叫 Bootloader（引导程序，操作系统启动前最先运行的代码），是你第一次真正掌控机器的代码。

有两个硬性要求必须满足，BIOS 才会认你：

代码必须放在内存 0x7C00 开始的位置
这 512 字节的最后两个字节必须是 0x55 0xAA（引导魔数，BIOS 用来识别可启动扇区的标志）

少一个，BIOS 直接忽略你。

实模式：CPU 刚醒来的状态

启动的时候，CPU 处于实模式（Real Mode，x86 最原始的工作模式，16 位寻址，最多访问 1MB 内存）。

实模式有一个好处：可以直接调用 BIOS 提供的中断服务（INT，软中断，通过中断号调用 BIOS 内置功能）。打印字符用的是 int 0x10，往 ah 里放功能号 0x0E，往 al 里放字符，中断一触发，字符就出现在屏幕上。

这是整个计算机世界里最"低级"的打印方式，但也是最直接的。

两个坑

第一次写这段代码，我卡在两个地方：

段寄存器没初始化。 实模式下内存寻址是通过"段:偏移"来算的，ds、es、ss（数据段、附加段、栈段寄存器）这些上来没初始化，地址算出来是错的。在代码开头手动清零就好。

栈没设置。 汇编代码里调用任何东西之前，栈（Stack，后进先出的内存区域，用于保存临时数据和返回地址）要先指到一个安全的地方。把 sp（栈顶指针）设成 0x7C00 就够了——往下增长，不会覆盖代码。

跑起来

写好汇编，用 NASM（汇编器，把汇编代码编译成机器码）编译成二进制，扔给 QEMU（开源的硬件模拟器，可以模拟一台完整的 x86 计算机）模拟器：

你好，大飞的博客

Wed, 06 May 2026 00:00:00 +0000

这是第一篇文章。

这个博客记录我用 AI 学技术的过程——从零写 Linux 内核、理解操作系统原理、各种踩坑实录。

内容不追求完美，追求真实。