简介西安电子科技大学计算机科学与技术专业的操作系统课程设计资料包面向需要完成系统级课程设计、大作业或毕业设计的学生适合具备一定编程基础、希望参考完整设计与实现流程的学习者。压缩包大小约41.16MB内含课程设计报告、实验代码以及原始上机截图等文件报告用于梳理设计背景、思路与模块划分代码可辅助对照关键算法的具体实现上机截图则为运行结果提供了真实环境下的验证依据。该资源已有604人浏览学习可作为操作系统实验、课程项目或初期项目立项的参照素材。内容覆盖从需求分析到编码调试的常见环节既能帮助初学者理解操作系统核心模块的工程化表达也能为进阶学习者提供排错与功能扩展的切入点。需要说明的是这份资料应作为参考资料而非定制需求使用者需具备一定基础查看并调试代码自行解决报错、按需添加功能后再用于自己的项目。1. 操作系统课程设计不玄学先想清楚你要交付什么西安电子科技大学计算机科学与技术专业的操作系统课程设计通常不是让你从头写一个 Linux而是给定一个实验框架常见的有 xv6、Linux 内核模块、或基于 QEMU 的模拟环境让你在有限时间内实现一到两个内核级功能模块。换句话说评判标准不是你“读懂了多少理论”而是你能不能在真机上或仿真环境里跑出一个可观测、可验证的结果。很多同学在这个环节翻车不是因为代码能力不够而是把精力花在了“读懂源码”上忽视了设计文档和验收脚本的准备。这篇笔记我按自己的血泪经验把从选题、环境搭建、代码实现到答辩验收的完整路径拆给你全程可复现参数给到能直接抄的程度。2. 选一个不劝退的课题六大方向、难度、交付物与陷阱课程设计最忌讳的事是第一天就扎进源码里看了一周还不知道自己要做的是什么。我一般会先花一个晚上把选题定死因为后面的所有工作——环境、模块划分、测试用例——都依赖这个决定。以下六个方向是西电及同类高校操作系统课程设计里最常见、也最容易做出成果的按我个人的推荐程度排序。2.1 基于 xv6 增加系统调用性价比最高的入门选项xv6 是 MIT 的教学用 Unix 变种代码体量只有几千行riscv 版本在 QEMU 下跑起来很快非常适合做系统调用类题目。常见的做法是给 xv6 新增一个语义明确的系统调用比如sys_getppid(void)返回父进程 PID或者做一个更实用的sys_getprocinfo把指定进程的 PID、状态、父进程 PID、运行时间、内存页数等内容写到用户态缓冲区。xv6 的系统调用链路非常清晰用户态通过ecall陷入内核内核根据syscall number跳转到对应的sys_xxx函数参数从a0、a1寄存器或用户栈上取出。你只需要改四个文件syscall.h加编号、syscall.c加函数指针映射、sysproc.c或proc.c写实现、用户态头文件里加声明。这个方向的好处是验收时可以现场演示“普通程序调用自己写的系统调用并打印结构化信息”无论考官问什么你都能从代码链路一路讲下去。2.2 Linux 内核模块面向真实内核但调试成本翻倍如果你不想碰教学系统想直接基于你机器上的 Linux 做实验内核模块是最合适的载体。模块可以动态加载和卸载不需要反复编译整个内核开发迭代速度比改 xv6 快得多。常见选题包括实现一个只读的/proc文件来暴露系统信息、修改进程调度策略、或者用netlink实现一个简单的内核态与用户态通信通道。这里的关键参数是内核头文件版本必须和你当前运行内核完全一致。很多人在 Ubuntu 上用apt install linux-headers-$(uname -r)装好头文件结果insmod时报version magic不匹配因为系统自动更新了内核但头文件装的是旧版本。拷机前务必核对uname -r的输出和你实际使用的头文件版本。另外模块里不能轻易调用printk之外的常规库函数除法、浮点、大内存分配都是坑这些我在第 5 章展开。2.3 自制简易调度器理论最丰富但验证难度大想做调度器方向的同学通常是觉得抢占、时间片、优先级这些理论“懂了”想自己实现一个来验证。这个方向的交付物一般分为两类一类是修改 xv6 的 Round-Robin 调度器改成基于优先级的调度或多级反馈队列另一类是脱离内核写一个独立的模拟器用多线程模拟进程模型主线程扮演 CPU 来按策略调度。我的建议是优先选前者因为真实内核里有中断、上下文切换、锁这些约束做出来的东西有说服力纯模拟器很容易被考官追问“你这和普通的生产者消费者模型有什么区别”。实现多级反馈队列时要注意时间片大小的选择直接决定演示效果——队列 0 的时间片设 2 个 tick队列 1 设 4 个 tick队列 2 设 8 个 tick这种 2 的幂的设置能让 CPU-bound 进程逐级下沉交互型进程优先响应演示时开两个进程分别模拟 I/O 密集和计算密集效果非常直观。2.4 文件系统模拟实验量可控但形式大于内容文件系统方向通常不看磁盘而是做一个基于内存的文件系统或者用户态 FUSE 文件系统。内存文件系统的实现相对独立包括磁盘块管理、inode 表、目录项解析、文件的创建删除读写。难在保证可靠性和异常处理上——做一个能演示的文件管理器不难难的是随机断电后不丢文件以及目录层级嵌套时路径解析正确。FUSE 方案更“工程化”因为可以让你的文件系统真的被mount到系统目录树里用户可以用ls、cat操作你实现的文件系统演示效果非常震撼。但 FUSE 的调试链路长内核的 FUSE 模块 →/dev/fuse设备 → 用户态守护进程 → 你的 FUSE 文件系统实现任何一层出错都表现为“挂载失败”或“目录打不开”新手会直接懵。如果你之前没做过用户态 Unix 编程这个方向的排错压力会比较大。2.5 内存管理实验页表与缺页异常的场景很难搭内存管理方向的常见形态是修改 xv6 的页表代码实现 lazy allocation 或写时复制COW。xv6 的uvmalloc、uvmcopy和缺页处理函数trap里的实现都是短小精悍的改动量通常不超过 200 行但理解成本高。lazy allocation 的思路很简单——malloc 时先不分配物理页只在页表里做标记等到进程访问时才触发缺页异常在异常处理里分配物理页。这个方向难点不在代码而在验证环境的搭建你需要写一个用户态测试程序故意访问未分配的内存观察内核是在哪一层拦下来的还要区分page fault是发生在用户态还是内核态。如果是后者内核直接 panic很难定位。所以这个方向适合对 RISC-V 特权架构有把握的同学新手慎重。2.6 传统外设驱动方向需要硬件环境慎选有些题目会给到真实开发板比如树莓派或某 ARM 板卡让你写 GPIO 中断或 I2C 设备的驱动。这个方向在实验室有硬件时是最出彩的——因为能物理看到 LED 闪烁或传感器读数。但硬件调试的坑是玄学级别的串口打印乱码可能是波特率配置错误也可能是 USB 转串口芯片驱动坏了GPIO 中断不来可能是设备树配置不对也可能是你触发了焊盘虚接。如果你没有 24 小时能守着开发板的物理条件我建议绕开这个方向除非题目强制指定。3. 环境搭建从 Windows/WSL2 到 QEMU 与 GDB 调试链选定方向后下一步是搭一套“改了代码能立刻跑、出错了能断点看”的开发环境。这一步最花时间也最容易被忽视因为很多人觉得“不就是编译吗make一下就好了”。实际上 90% 的进度停滞都发生在环境不一致上——你在 WSL 里编译出来的 xv6 内核镜像拿到答辩教室的 Windows 上用不同版本的 QEMU 启动很可能直接黑屏。所以我的建议是从第一天就把开发、编译、运行、调试锁死在同一套环境里。3.1 WSL2 下安装工具链gcc、qemu、gdb-multiarch在 Windows 上做 xv6 实验最省事的路径是 WSL2 Ubuntu 发行版。先在 WSL 里更新软件源并安装基础工具链sudo apt update sudo apt install -y build-essential gdb-multiarch qemu-system-misc \ git vim tmux这里有两个参数需要特别注意。qemu-system-misc在 Ubuntu 源里对应的是常规 RISC-V 模拟器安装后确认qemu-system-riscv64在 PATH 中。有些同学习惯装qemu-system-x86结果启动 RISC-V 镜像时报 “no bootable device”因为 CPU 架构根本不匹配。gdb-multiarch则是支持多架构的调试器连接 RISC-V 内核时用riscv64-unknown-elf-gdb个人维护的版本反而不如官方源里的 multiarch 稳定。装完后先跑一下riscv64-unknown-elf-gcc --version如果提示找不到直接装gcc-riscv64-unknown-elf这个交叉编译包因为 xv6 的 Makefile 默认用的就是这前缀的编译器。接下来验证 QEMU 能正常模拟 RISC-V 机器。这里有个提高效率的小技巧在~/.bashrc里加一个别名把 QEMU 的显示窗口关掉改成串口控制台模式alias qemu-xv6qemu-system-riscv64 -machine virt -nographic -bios none -kernel /path/to/xv6/kernel -m 128M-nographic的作用是把 QEMU 的输入输出重定向到当前终端避免弹出一个不可控的 SDL 窗口——在远程 SSH 或 WSL 无显示环境下尤其好用。-m 128M给虚拟机分配 128MB 内存xv6 默认只用到 128MB 以下的物理地址空间设置过大反而可能导致部分实验比如 lazy allocation 测试表现和预期不一致。3.2 用 Makefile 管住编译目标而非裸敲 gcc很多学生习惯自己手写编译命令这在小型系统编程里会很快失控。xv6 自带 Makefile你只需要理解几个核心 targetmake qemu编译并启动make qemu-gdb会停住等待 GDB 连接make clean清除产物。改完代码后最稳妥的复现流程是这样cd xv6-labs-2023 make clean make qemu先把make clean放在前面避免旧的.o文件干扰链接结果。xv6 的链接脚本kernel.ld会把内核加载到固定的物理地址0x80000000如果你改了链接脚本或新增了目标文件而不 clean链接时可能出现 “section .text will not fit in region” 这类错误此时第一反应应该是 clean 而不是去查源码。新增源文件时记得在 Makefile 的OBJS变量里手动追加对应的.o文件。xv6 的 Makefile 有一个细节经常坑人它用wildcard自动收集目录下的.c文件但只在特定规则下生效如果你把.c文件放在子目录而没改 Makefile 的CFLAGS加头文件路径编译时会报 “No such file or directory”。我自己的做法是所有新增源码都放在根目录用xv6_前缀命名比如xv6_procinfo.c这样既有辨识度又不需要改 Makefile 的搜索路径。3.3 GDB 断点调试内核黑匣子之外的唯一窗口在 QEMU 里跑 xv6printf是基本的观测手段但碰上死锁或死循环还是得靠断点。启动调试会话的步骤是先开一个终端跑make qemu-gdb再开另一个终端执行gdb-multiarch kernel/kernel(gdb) target remote localhost:26000 (gdb) b sys_proc_dump (gdb) c这里的端口26000是 xv6 Makefile 里写死的 QEMU GDB stub 端口。断点可以打在 C 函数上也可以打在具体地址上。遇到“内核启动后卡死”的场景我一般会在scheduler()和trap()各下一个断点看是调度循环进不去还是中断处理死循环。GDB 连接不上时优先确认 QEMU 是否还在等待连接——如果你之前没执行过make qemu-gdb直接连 GDB 会提示connection refused反过来如果 QEMU 已经进入正常启动流程而你还去连 GDB也会失败因为-s参数只在qemu-gdbtarget 里启用。3.4 备份整套环境的后悔药tar 打包 版本锁定环境搭好后第一件事不是写代码而是把整套环境打一个快照防止答辩前夜系统崩掉。我一般做两层备份第一层是 WSL 发行版导出用wsl --export把整个 Ubuntu 导出为 tar 文件第二层是只备份项目和工具链版本号cd /path/to/project tar czf ~/xv6-env-backup.tar.gz . dpkg -l | grep -E qemu|gcc-riscv|gdb-multiarch ~/env-packages.txt第二层备份的文件很小但信息量很大——一旦换机器apt install对应版本的工具链就能恢复一致环境。我见过不止一个小组答辩当天发现 QEMU 版本和课程要求不一致导致启动参数不兼容屏幕上只有光标闪烁那种情况重装环境已经来不及了有备份至少能保证演示是成功的。4. 实现一个完整的内核功能模块系统调用落地全流程这一章我以“新增一个sys_getprocinfo系统调用”为例子把从用户态到内核态的完整实现链条走一遍。选这个功能是因为它足够小、足够直观而且能同时考察你对进程表、锁、用户态参数传递这些核心机制的掌握程度。4.1 定义系统调用编号与函数原型表xv6 的系统调用编号定义在kernel/syscall.h里。打开这个文件你会看到类似#define SYS_fork 1的一系列宏定义。新增调用时先找一个空位比如#define SYS_getprocinfo 23然后把函数指针挂到kernel/syscall.c的静态函数表syscalls中同时添加一个外部声明extern uint64 sys_getprocinfo(void); static uint64 (*syscalls[])(void) { [SYS_fork] sys_fork, [SYS_exit] sys_exit, ... [SYS_getprocinfo] sys_getprocinfo, };注意这里用了 C 语言的指定初始化器designated initializer所以如果你的编号有跳跃不要按顺序补全所有空位只把 23 号映射上即可。初始化器的好处是表项顺序和编号解耦编译时如果编号超出数组范围编译器会直接报错能第一时间发现宏定义写错。4.2 实现内核函数本体遍历进程表并拷贝到用户态接下来在kernel/proc.c里实现sys_getprocinfo。这个函数的核心逻辑是三步找到当前进程或指定 PID 的进程、读取进程的struct proc字段、把数据拷贝到用户态缓冲区。uint64 sys_getprocinfo(void) { struct proc *p; int pid; struct procinfo info; // 从用户态栈上读取 PID 参数 if (argint(0, pid) 0) return -1; // 遍历进程表找到匹配的进程 for (p proc; p proc[NPROC]; p) { acquire(p-lock); if (p-pid pid) { // 填充待返回的结构体 info.pid p-pid; info.ppid (p-parent 0) ? -1 : p-parent-pid; info.state p-state; info.sz p-sz; info.nice p-nice; // 若未实现优先级此字段可删 release(p-lock); // 把结果从内核态拷贝到用户态地址 if (copyout(p-pagetable, (uint64)addr, (char *)info, sizeof(info)) 0) return -1; return 0; } release(p-lock); } return -1; }这段代码有几个必须说明的细节。argint(0, pid)是从用户栈里取出第 0 个整数参数xv6 的系统调用参数传递约定是参数放在a0-a5寄存器或用户栈上内核必须用argint、argaddr这些辅助函数来访问绝不可以直接解引用用户传递的指针——那是一个用户态地址内核无法直接读写。acquire(p-lock)是遍历进程表时必须拿的自旋锁。xv6 的进程表是全局数组多个 CPU 可能同时访问不拿锁会触发输出乱码甚至死锁。注意我在info.pid p-pid之后先行release再copyout这个顺序很重要copyout可能触发页表遍历耗时不可控如果一直持有p-lock可能和allocproc里的锁操作形成竞争条件。还有一个隐藏的坑是p-parent-pid这行代码。parent指针可能指向一个已释放的进程此时访问parent-pid属于悬垂指针。在 xv6 的进程退出流程exit()中父进程会把子进程收养所以正常情况不会悬垂但极端场景比如你同时测试进程并发退出还是会出现的。保险做法是用p-parent是否为空来判断且遍历时同样保护p-parent-lock——不过这里为了代码简洁我直接用(p-parent 0) ? -1 : p-parent-pid兜底。4.3 用户态封装从系统调用到可调用的 C 函数内核里实现了功能还不够用户态程序需要拿到一个声明才能让编译器生成正确的ecall指令。xv6 的用户态库函数在user/user.h中声明在user/usys.pl中生成汇编跳板// user.h int getprocinfo(int pid, struct procinfo *info);usys.pl里加对应的一行参数模板entry(getprocinfo);这一行会被usys.S展开成一段汇编把系统调用编号SYS_getprocinfo加载到a7寄存器然后执行ecall内核返回后继续执行用户态代码。这个过程中用户态传入的struct procinfo *info是一个虚拟地址内核里copyout的目标地址就是它——千万不要把用户态的地址直接当作内核指针用这就是教学系统里强调的“用户态与内核态地址空间隔离”。4.4 测试程序与 Makefile 集成让验收可一键执行最后写一个用户态测试程序user/procinfo_test.c把新系统调用暴露的信息打印出来#include kernel/types.h #include kernel/stat.h #include user/user.h int main(void) { struct procinfo info; if (getprocinfo(getpid(), info) 0) { printf(getprocinfo failed\n); exit(1); } printf(PID: %d, PPID: %d, State: %d, Size: %d\n, info.pid, info.ppid, info.state, info.sz); exit(0); }然后在 xv6 的 Makefile 里把procinfo_test加入UPROGS变量UPROGS\ _procinfo_test\ ...在 xv6 控制台里直接输入procinfo_test即可运行。这里有一个常见的现象你运行测试程序时看到的 PPID 是 shell 的 PID通常是 1 或 2这正好是验证进程父子关系的一个佐证。千万不要小看这最后的 Makefile 集成步骤——很多同学实现了系统调用但忘了把测试程序编进镜像答辩时只能在用户态里手动gcc一个无法链接系统调用的二进制那种尴尬我见过不少次。5. 调试与避坑内核实验最容易翻车的 5 个现场内核编程的调试手段比普通应用开发少一个数量级——没有段错误的直接提示没有 strace 可以抓系统调用。下面这几条是我自己在 xv6 和 Linux 模块上真实踩过的坑每条都按“现象 → 原因 → 解决”讲清楚。5.1make qemu黑屏或无限重启现象终端只显示 QEMU 的启动横幅或者内核刚打印几行就重启循环。原因十有八九是你改了内核代码后引入了死锁或访存异常panic信息被刷屏了。先不要慌把输出往上翻找panic:开头的行那里会直接告诉你出错的文件和行号。如果连 panic 都没有只在0x80000000初始化后就卡住很大概率是链接脚本或entry.S里地址配置有问题。解决办法是先用原始的 release 版本跑一遍确认环境完好再逐个追加你的改动二分定位哪一次修改引入了问题。5.2 系统调用返回-1用户态程序报 failed现象getprocinfo调用返回-1但内核代码逻辑看着没问题。常见原因有两个一是系统调用编号冲突你写成 23但其他的分支已经占用了 23导致跳到了完全不同的函数——打开syscall.h仔细数一下别只搜“23”是否出现过要看整体序列是否有重复。二是参数传递失败argint在用户态栈上没找到你期望的数字。这种时候在syscall.c里临时加一个printf打印传入的pid值和函数指针立竿见影。5.3 Linux 内核模块insmod报Invalid module format现象编译模块没报错insmod时却返回Invalid module formatdmesg里是version magic不匹配。原因是你编译模块用的内核头文件和当前运行内核不一致——最常见是 Ubuntu 自动更新了内核/usr/src下有两个版本的目录Makefile 里的KERNELDIR指向了旧版。解决uname -r ls /usr/src/linux-headers-$(uname -r) make -C /usr/src/linux-headers-$(uname -r) M$(pwd) modules核心是-C指向的路径必须逐字符匹配uname -r的输出。还有一种情况是头文件装了但没装linux-libc-dev同样会让编译和运行版本错位apt install linux-libc-dev可解。5.4 xv6 中printf输出乱码现象内核里用printf打印调试信息时输出是一堆不可读字符或重叠刷屏。原因有二一是你没拿自旋锁就访问了共享数据结构数据在打印的过程中被其他 CPU 改写二是新的 C 文件没有#include kernel/types.h这类基础头文件导致结构体字段对齐方式不对。解决方法是先查有没有release(p-lock)被遗漏再看编译时有没有缺头文件的警告。xv6 的 printf 本身是线程安全的它内部有锁所以乱码几乎可以断定是数据源的问题。5.5 在 WSL2 里用make qemu键盘输入失效现象QEMU 跑起来了内核打印正常但按键盘没反应无法输入命令。原因不是你的键盘坏了而是 WSL2 的终端重定向模式与 QEMU 的-nographic有兼容问题特别是在 Windows Terminal 里跑旧版 QEMU。解决办法有两个一是把 QEMU 换成qemu-system-riscv64 -nographic -serial mon:stdio强制把串口绑到标准输入输出上二是在 WSL2 里用tmux开启一个会话再跑 QEMUtmux 的输入处理更干净。如果你用的是非 Windows Terminal 的终端还考虑装rlwrap包一层但一般不必要先试第一种方案。6. 验收前的最后一小时演示脚本、README 与追问防御课程设计答辩的实质是你要在一个有限时间内让不懂代码细节的评委相信你不仅写对了而且知道为什么这么做。这最后一个小时我不会再看代码只做三件事写一个一键演示脚本、整理 README、把最容易追问的三个问题想透。演示脚本的核心是让评委“自己动手看到一个结果”。在 xv6 里做的话我会写一个 shell 脚本来执行一连串的命令并打印输出# demo.sh 在 xv6 用户态执行 echo 1. 调用 getprocinfo 获取当前进程信息 procinfo_test echo 2. 连续创建 5 个子进程验证 PID sh test_fork_loop.sh echo 3. 查看内核日志确认系统调用链路 ctrl-p如果系统不支持 shell 脚本也可以用一个批处理入口程序连续调用getprocinfo并输出表格。关键是输出的格式要整齐——对齐的 PID 和 PPID 表比一次 printf 更容易让评委员感受到“这是个正经实现”。README 我一般会写三段第一段是这个模块做了什么用两句话第二段是设计思路包括数据结构的选择和为什么加这个锁第三段是测试步骤从make clean到make qemu再到运行测试程序的完整命令序列。最后的追问防御更简单——自己扮演评委问自己三个问题“如果 PID 不存在时你的函数返回什么”、“为什么这个遍历要加锁而不是用原子变量”、“如果两个 CPU 同时调用这个系统调用会怎样”把答案写在 README 末尾不用展开但要真正理解。做完这三件事剩下的时间全部用来跑三遍完整流程make clean make qemu、运行 test、截图记录输出。答辩现场最怕的不是功能不强大而是你自己连演示步骤都忘了。这十几年里我做过很多系统级的项目有一个体会是操作系统的实验很少是“启动不了就是代码写错”更多时候是你对环境、对流程的理解有缺口。把每一步都拆到能复现把每一个指令的参数和含义都搞清楚你交付的就不只是一份课程设计而是一套你真正能驾驭的底层系统能力。希望今天这篇笔记里的参数和避坑清单能让你少走几个我当年走过的弯路祝你的课程设计一次通过。本文还有配套的精品资源点击获取