Posts

前几章的文件系统是存在内存里的——重启数据就没了，文件名也是硬编码的。这一章做真实的：挂载一个 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 驱动的用武之地。 ...

前面的文件系统都是存在内存里的——重启数据就没了。要读真实磁盘，得先搞清楚操作系统怎么和磁盘"说话"。这一章做 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 命令（写）/ 状态（读） 状态寄存器的两个关键位： ...

前十二章，内核从一个 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 是终端删除字符的标准做法：退格、打空格覆盖、再退格。 ...

上一章我们写了一个 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 号和对应的函数指针表。对上层完全屏蔽了底层差异。 ...

到目前为止，内核能跑进程、能做系统调用，但所有数据都在内存里——进程一死，什么都没了。 这一章做文件系统：把数据写到"磁盘"（我们用内存模拟），下次还能读回来。 先把概念搞清楚 动手之前，先理解五件事。 为什么需要文件系统 磁盘本质上就是一个大字节数组。没有文件系统，你只能说"读第 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。 这五个概念搞清楚，下面的代码就是它们的直接翻译。 文件系统解决什么问题 内存是易失的，文件系统负责两件事： ...

前几章的"进程"其实是假的——它们直接跑在内核态，和内核同等权限，可以随意读写任何内存、操作任何硬件。 真实的操作系统里，用户程序跑在用户态（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 个： ...

到目前为止，内核一直是单线程跑到底——一件事没做完，别的什么都不能干。 这一章让内核同时跑多个进程。每隔一段时间，时钟中断打断当前进程，把 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。 ...

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）作为起始堆空间，不够了再动态扩展。 ...

上一章内核能分配物理页了，但用的全是物理地址。 物理地址有个问题：全局唯一，谁都能访问。进程 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，高位是下一级页表（或最终物理页）的地址。 ...

内核跑起来之后，第一个绕不开的问题就是内存。 你不知道这台机器有多少内存，哪些地址段可以用，哪些是硬件保留的。如果随便往一个地址写数据，轻则数据损坏，重则触发异常直接重启。 这一章解决一件事：让内核知道内存的全貌，然后有序地分配和回收物理页。 先问 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 上跑出来的内存地图一般长这样： ...