别再被挂载搞晕了！手把手教你搞定Linux 0.11系统调用实验（附完整路径避坑指南）

从零攻克Linux 0.11系统调用实验：一份让路径困惑彻底消失的实战手册

第一次接触Linux 0.11系统调用实验时，我盯着屏幕上oslab/hdc/usr/root这一串路径发了半小时呆——明明按照教程操作，却总是遇到"文件不存在"的报错。直到深夜才发现，原来挂载操作才是解锁这一切的钥匙。这份指南将用最直白的语言，带你穿越那些教程里没人说清的"暗坑"，把系统调用实验拆解成可复制的操作单元。

1. 实验环境准备：避开挂载的认知陷阱

多数教程默认你已经理解挂载的概念，但恰恰是这一步让80%的初学者卡壳。Linux 0.11实验环境中的hdc目录，实际上是虚拟硬盘的访问入口。未挂载时，它只是个空壳目录；挂载后才会显示真实内容。

1.1 关键目录结构解析

先明确几个核心路径的关系：

oslab/ ├── hdc/ # 虚拟硬盘挂载点（空目录） ├── linux-0.11/ # 内核源代码 └── mount-hdc # 挂载脚本

挂载前后的区别：

• 未挂载时：hdc/usr/root路径不存在
• 挂载后：hdc/usr/root可访问用户程序文件

1.2 挂载操作的正确姿势

执行挂载时最容易犯的两个错误：

1. 在错误路径执行命令（必须在oslab/目录下）
2. 忘记使用sudo权限

正确的操作序列：

cd oslab/ # 确保当前目录正确 sudo ./mount-hdc # 执行挂载 ls hdc/usr/root # 验证是否出现预期内容

重要提示：每次修改用户程序后必须卸载才能启动Bochs虚拟机，否则修改不会生效

2. 用户程序开发：从代码到可执行文件

2.1 程序存放的黄金路径

必须在挂载状态下将程序放在特定位置：

# 进入用户程序目录 cd hdc/usr/root # 创建测试程序 touch iam.c whoami.c

2.2 系统调用宏的魔法

理解_syscall1和_syscall2宏的差异：

• _syscall1：处理单参数调用（如iam）
• _syscall2：处理双参数调用（如whoami）

示例代码结构对比：

2.3 编译测试的隐藏技巧

在Bochs中编译时添加-Wall参数能发现潜在问题：

gcc -o iam iam.c -Wall gcc -o whoami whoami.c -Wall

常见编译错误解决方案：

• "undefined reference toiam"：检查__LIBRARY__宏定义
• "implicit declaration"：确认<unistd.h>包含正确

3. 内核修改实战：五步完成系统调用植入

3.1 系统调用号分配

在include/unistd.h中添加时要注意：

• 号码必须连续且唯一
• 建议在原有末尾号码后递增

示例修改：

#define __NR_whoami 72 # 原系统调用最后编号是71 #define __NR_iam 73

3.2 系统调用表更新

include/linux/sys.h需要两处修改：

1. 函数声明添加：

extern int sys_iam(); extern int sys_whoami();

2. 函数指针数组添加：

fn_ptr sys_call_table[] = { ..., sys_iam, # 第72项 sys_whoami # 第73项 };

3.3 内核函数实现要点

在kernel/who.c中需要注意：

• 用户态到内核态的数据拷贝使用get_fs_byte
• 内核态到用户态使用put_fs_byte
• 字符串操作要手动处理（不能用libc的strcpy）

安全边界检查示例：

int sys_iam(const char *name) { char tmp[30]; int len = 0; // 逐字节拷贝并检查长度 while(len < 30 && (tmp[len] = get_fs_byte(name + len))) len++; if(len > 23) { return -EINVAL; # 超出限制返回错误 } // 安全拷贝 for(int i=0; i<=len; i++) msg[i] = tmp[i]; return len; }

3.4 Makefile修改陷阱

在kernel/Makefile中需要：

1. 添加who.o到OBJS列表
2. 在依赖规则中添加who.s who.o: who.c ../include/...

典型错误模式：

OBJS = ... who.o # 遗漏此项会导致链接失败

3.5 编译验证的正确流程

完整的构建检查清单：

make clean # 清除旧编译结果 make all # 完整编译 ./dbg-bochs # 启动调试环境

4. 测试与调试：确保系统调用真正生效

4.1 基础功能测试

测试用例设计建议：

1. 正常情况测试：

./iam "Linux" # 写入合法字符串 ./whoami # 应输出"Linux"

2. 边界测试：

./iam "12345678901234567890123" # 23字符(极限值) ./iam "123456789012345678901234" # 24字符(应失败)

4.2 错误处理验证

检查错误返回是否符合预期：

// 在whoami.c中添加测试代码 if(rlen == -1) { printf("Error: %s\n", errno == EINVAL ? "Buffer too small" : "Unknown"); }

4.3 高级测试技巧

使用脚本自动化测试：

#!/bin/sh echo "Running test cases..." ./iam "Test1" && ./whoami | grep -q "Test1" || echo "Test1 failed" ./iam "LongStringShouldFail" && ./whoami || echo "Test2 passed as expected"

5. 深度理解：系统调用的底层机制

5.1 参数传递限制分析

Linux 0.11使用寄存器传递参数：

• ebx：第一个参数
• ecx：第二个参数
• edx：第三个参数

这意味着：

• 超过3个参数需要特殊处理
• 大结构体需要通过指针传递

5.2 扩展参数数量的方案

如果需要支持更多参数，可以考虑：

1. 使用结构体打包参数

struct my_args { int arg1; char *arg2; long arg3; // ... }; _syscall1(int, foo, struct my_args*, args)

2. 通过堆栈传递额外参数（需修改汇编代码）

5.3 系统调用性能考量

在实现时应注意：

• 尽量减少用户态与内核态的数据拷贝
• 复杂操作可拆分为多个简单系统调用
• 错误检查应先于实际操作

6. 实验总结：那些只有踩过坑才知道的事

1. 挂载时机：每次修改用户程序后，必须卸载→启动Bochs→测试→再挂载修改，形成闭环

2. 路径幻觉：hdc/usr/root在未挂载时"看起来存在"，实际是假象，用ls命令实时验证

3. 内核编译缓存：有时make all不会重新编译所有内容，遇到奇怪问题先make clean

4. 测试顺序：先测试正常流程，再测边界条件，最后测错误处理，避免早期错误干扰判断

5. Bochs调试：遇到崩溃时，使用Bochs内置调试器查看寄存器状态：

<bochs:1> info registers <bochs:2> x /10i $eip