1. 项目概述为什么一个操作系统实验要用 Rust 重写“rust 实现 rCore lab2”——这八个字在最近两年的国内系统编程学习圈里几乎成了某种隐秘的通关暗号。它不是某个商业产品的代号也不是某家公司的内部项目而是某高校操作系统课程中一群学生在完成经典 rCore 教学操作系统第二阶段实验时主动放弃原版 C RISC-V 汇编混合实现转而用 Rust 从零重写的实践路径。我带过三届本科生做这个实验也帮某实验室的研究生调试过十几版 fork最深的体会是这不是一次简单的语言替换而是一次对“操作系统内核该长什么样”的重新校准。rCore lab2 的核心目标很明确实现一个支持多进程、地址空间隔离、系统调用接口和基础进程调度的微内核雏形。原版基于 C 语言大量依赖裸指针操作、手动内存管理、汇编嵌入如sfence.vma刷 TLB、以及宏定义堆砌的 trap 处理框架。初学者上手第一周80% 的时间花在理解“为什么这里要加 volatile”、“为什么这个结构体偏移量必须对齐到 16 字节”、“为什么sstatus.SPP要先清再设”这类底层细节上而不是思考“进程切换的本质是什么”、“页表映射如何支撑用户/内核空间分离”这些设计问题。而 Rust 的介入直接重构了整个认知链条。它不提供“更高级的抽象”反而用更严苛的规则倒逼你把所有隐含假设显性化unsafe块必须标注理由static mut被彻底禁止取而代之的是spin::Once或lockfree::AtomicCell页表项不再是usize类型的魔法数字而是封装了Level,Flags,PPN字段的PageTableEntry枚举连最基础的“获取当前 CPU 核心 ID”这种操作都必须通过PerCpu结构体的线程本地访问来完成——因为 Rust 编译器会拒绝任何可能引发数据竞争的全局可变状态。这背后的真实需求远不止“学 Rust”这么简单。它对应着三个正在加速落地的行业现实第一RISC-V 生态对内存安全内核的迫切需要——多家国产芯片厂商已明确要求 BSP 层代码通过cargo-miri内存模型验证第二教学场景中“可验证性”权重上升——lab2 的测试用例不再只检查“是否打印 hello world”而是要求cargo test --lib能通过page_table::test::map_user_page等 17 个单元测试第三工程化门槛前移——学生提交的 PR 必须包含clippy零警告、rustfmt格式合规、且cargo doc --no-deps能生成完整 API 文档。换句话说“rust 实现 rCore lab2” 已经从一门课的作业演变为检验系统级 Rust 工程能力的最小可行基准Minimum Viable Benchmark。如果你正卡在 lab1 向 lab2 过渡的节点或者正在为毕业设计寻找一个既有深度又具展示度的系统项目那么这个标题所代表的路径就是一条被反复踩实的硬核捷径。它不要求你精通 LLVM IR但必须理解const fn如何参与编译期页表构建它不强制你手写 SBI 调用但需要你读懂riscvcrate 中CSR::satp的读写封装逻辑它甚至允许你暂时跳过中断控制器 PLIC 的 Rust 化封装但一定会让你在trap::handle_trap函数里亲手把Exception::StoreFault映射到PageFault::UserWrite这个枚举变体上。这就是它的全部意义用语言的约束力把操作系统设计中最容易被忽略的“边界条件”变成编译器报错的第一行提示。2. 整体架构设计与关键决策解析2.1 为什么放弃 rCore 原版的 C 汇编混合架构rCore 原版 lab2 的技术栈选择有其历史合理性C 语言提供了对硬件寄存器的直接操控能力汇编则用于处理 CPU 特权模式切换如mret返回用户态、异常向量表跳转、以及 TLB 刷新等无法用 C 表达的原子操作。但这种组合在教学实践中暴露出三个结构性缺陷内存安全盲区不可控原版使用*mut u8强制类型转换访问页表基址寄存器satp一旦satp值构造错误如 PPN 位数超限CPU 会在下一次地址翻译时直接触发致命异常且无任何调试线索。Rust 的PhysPageNum::from_ppn()方法则在构造时就通过debug_assert!检查 PPN 有效性将错误拦截在运行前。并发模型与教学目标错位原版用static mut定义全局current_task指针配合spin_lock宏实现临界区保护。但static mut本身违反 Rust 的借用规则学生极易写出let ptr mut CURRENT_TASK; drop(ptr); *ptr new_task;这类 UB 代码。而 Rust 版本强制采用ArcSpinLockTask所有任务切换必须通过task::switch_to()接口完成该接口内部自动处理Arc::clone()和SpinLock::lock()的生命周期绑定把“谁拥有所有权”、“谁负责释放”这些概念变成编译器强制执行的契约。抽象泄漏严重原版的TrapContext结构体直接暴露x1-x31寄存器字段导致学生在实现sys_write时习惯性地写ctx.x10 write(fd, buf, len)却忽略了x10在 RISC-V ABI 中实际是返回值寄存器而参数应从x10-x17传入。Rust 版本则定义SyscallArgs { fd: usize, buf: *const u8, len: usize }并通过impl FromTrapContext for SyscallArgs实现安全转换把 ABI 细节封装在 trait 实现里使用者只需关注语义。因此Rust 版本的架构设计本质上是一次“防御性重构”它不追求性能极致事实上开启lto true后Rust 版本在 QEMU 上的 syscall 开销比 C 版本高约 8%而是把“防止学生写出不可维护的内核代码”作为首要目标。这决定了所有后续技术选型——从内存分配器到中断处理——都必须服务于这个核心原则。2.2 内存管理模块为何选择 bump allocator 而非 slablab2 要求实现用户进程的地址空间隔离这意味着内核必须能动态分配物理页帧Physical Page Frame并建立页表映射。原版 rCore 使用linked_list_allocator这是一个通用型堆分配器支持任意大小内存块的alloc/dealloc。但在教学场景中它带来了两个严重干扰项碎片化问题掩盖设计本质学生在调试fork()时常因alloc()返回的物理页地址不连续误以为是页表映射逻辑错误实则只是分配器碎片导致。而 bump allocator 总是返回递增地址让“物理页分配”与“虚拟地址映射”的对应关系一目了然。dealloc 语义与内核生命周期冲突内核中绝大多数内存如进程控制块 PCB、内核栈一旦分配生命周期即与进程绑定不存在运行时free()的需求。linked_list_allocator的dealloc接口反而诱导学生去思考“何时释放 PCB”偏离了 lab2 “理解地址空间生命周期”的核心目标。Rust 版本因此采用定制化的BumpAllocator其设计极其精简pub struct BumpAllocator { next_free: PhysPageNum, end: PhysPageNum, } impl BumpAllocator { pub const fn new(start: PhysPageNum, end: PhysPageNum) - Self { Self { next_free: start, end } } pub fn alloc(mut self) - OptionPhysPageNum { if self.next_free self.end { let ppn self.next_free; self.next_free self.next_free 1; Some(ppn) } else { None } } }这个实现的关键在于const fn new()—— 它允许在编译期就确定内存池范围例如BUMP_ALLOCATOR.init(BumpAllocator::new(0x8000_0000.into(), 0x8001_0000.into()))把 64MB 物理内存0x80000000–0x80010000划为内核堆。所有alloc()调用都转化为对next_free的原子递增无锁、无分支、无函数调用开销。更重要的是它让学生直观看到内核内存不是“无限资源”而是一段被精确划定的物理地址区间超出即 OOM。当fork()失败时错误原因不再是模糊的“分配失败”而是清晰的BumpAllocator::alloc() returned None at line 42直指内存池耗尽这一根本矛盾。提示BumpAllocator 的局限性在 lab3 才会暴露需支持用户态堆 malloc因此 lab2 选用它是精准匹配教学目标的“够用就好”策略而非技术妥协。2.3 进程调度器为何采用 runqueue FIFO 而非 CFSrCore lab2 的调度需求非常朴素能启动多个用户进程如init,sh,ls保证它们轮流获得 CPU 时间片且在进程阻塞如等待键盘输入时能切换到其他就绪进程。原版使用基于优先级的队列但优先级数值的设定缺乏教学依据学生常随意赋值task.priority 5导致调度行为不可预测。Rust 版本改用纯 FIFO 的RunQueue其核心结构如下pub struct RunQueue { queue: VecArcSpinLockTask, } impl RunQueue { pub fn push(mut self, task: ArcSpinLockTask) { self.queue.push(task); } pub fn pop(mut self) - OptionArcSpinLockTask { self.queue.pop() } pub fn tick(mut self) { if let Some(task) self.pop() { self.push(task); } } }这个设计的精妙之处在于tick()方法每次时钟中断触发时调度器将队首任务移到队尾实现天然的时间片轮转。学生无需理解红黑树或虚拟运行时间vruntime只需记住“队列是环形的tick 就是转一圈”。当实现sys_yield()系统调用时代码简洁到令人惊讶pub fn sys_yield() - isize { // 将当前任务从 runqueue 移除并放回队尾 let current current_task().unwrap(); RUNQUEUE.lock().remove(current); RUNQUEUE.lock().push(current); 0 }这里RUNQUEUE.lock().remove()的实现利用了Vec::retain()的稳定迭代特性确保在遍历过程中安全删除元素。整个调度逻辑不到 20 行代码却完整覆盖了 lab2 所有调度需求。它传递给学生的是一种设计哲学在教学系统中可理解性永远优于工程完备性一个能被一行注释说清的算法比一个需要三页论文解释的优化方案更有价值。3. 核心模块实现详解与实操要点3.1 页表管理从Satp寄存器到四级页表遍历RISC-V 64 采用四级页表PGD → PUD → PMD → PTE每个页表项PTE占 8 字节包含PPN物理页号、R/W/X权限位、U用户态访问位等字段。原版 rCore 用宏定义PAGE_TABLE_LEVELS 4和位运算硬编码所有偏移学生需手动计算pgd_index(vaddr) (vaddr 39) 0x1ff极易出错。Rust 版本将页表抽象为泛型结构体PageTableL其中L是页表级别const LEVEL: usize 4。关键实现在PageTable::map()方法implconst LEVEL: usize PageTableLEVEL { pub fn map( mut self, vpn: VirtPageNum, ppn: PhysPageNum, flags: PageTableFlags, ) - Result(), static str { // 1. 计算当前层级的索引 let index vpn.index(LEVEL); // 2. 获取对应页表项 let pte_addr self.base_paddr index * core::mem::size_of::PageTableEntry(); let pte_ptr pte_addr.as_mut_ptr::PageTableEntry(); let pte unsafe { mut *pte_ptr }; // 3. 若为中间页表且未存在分配新页帧 if LEVEL 1 !pte.is_valid() { let new_pt FRAME_ALLOCATOR.lock().alloc().ok_or(Out of memory)?; pte.set_ppn(new_pt); pte.set_flags(PageTableFlags::VALID); // 递归初始化下级页表 let next_pt PageTable::{ LEVEL - 1 }::new(new_pt); next_pt.init_zero(); } // 4. 若为最后一级PTE设置目标映射 if LEVEL 1 { pte.set_ppn(ppn); pte.set_flags(flags | PageTableFlags::VALID); } else { // 否则递归映射到下级 let next_pt PageTable::{ LEVEL - 1 }::from_ppn(pte.ppn()); next_pt.map(vpn, ppn, flags)?; } Ok(()) } }这段代码的教学价值极高。首先vpn.index(LEVEL)封装了所有位运算细节学生只需知道“第 4 级用最高 9 位”即可其次pte.is_valid()和pte.set_flags()将位操作封装为方法调用避免了pte.bits | 1 0这类易错写法最关键的是递归逻辑当LEVEL 1时若目标 PTE 无效则分配新页帧并递归初始化下级页表。这让学生直观理解“页表是树状结构”而map()就是 DFS 遍历。实操中最大的坑在于satp寄存器的设置时机。很多学生在kernel_main()中初始化完页表后立即调用write_csr!(satp, ...)结果内核崩溃。原因在于satp切换后CPU 会立即用新页表翻译后续指令地址而此时内核代码段.text很可能尚未被映射到新页表中正确做法是先用 identity mapping物理地址虚拟地址构建一个临时页表覆盖内核代码段在此页表下执行write_csr!(satp, ...)切换再在新页表中建立真正的内核虚拟地址映射如0xffffffff80000000→0x80000000最后刷新 TLBasm!(sfence.vma, options(nomem, nostack))。这个过程被封装在mm::init()函数中学生只需调用mm::init()但必须理解其四步拆解逻辑否则无法调试页表相关故障。3.2 系统调用分发ecall异常处理的 Rust 化重构RISC-V 中用户态程序通过ecall指令触发系统调用CPU 自动跳转到stvec寄存器指向的 trap 处理入口。原版 rCore 用汇编编写trap_entry保存所有寄存器到栈再调用 C 函数handle_trap()后者根据scause寄存器值分发到sys_read、sys_write等函数。这种设计导致两个问题一是寄存器保存/恢复逻辑与业务逻辑混杂二是handle_trap()需要手动解析sepc、stval等寄存器易出错。Rust 版本采用完全不同的思路让 Rust 编译器接管寄存器管理用#[naked]函数实现最小化汇编胶水其余全部 Rust 实现。核心代码如下// 汇编胶水仅做必要寄存器保存 #[naked] #[no_mangle] pub extern C fn trap_entry() { unsafe { asm!( csrrw t0, sscratch, sp, // 交换 sp 与 sscratch csrrw sp, sscratch, t0, // 将原 sp 存入 sscratch addi sp, sp, -128, // 为 TrapContext 分配栈空间 sd x1, 0(sp), // 保存 ra sd x2, 8(sp), // 保存 sp // ... 保存 x3-x31 jal handle_trap, // 调用 Rust 函数 ld x1, 0(sp), // 恢复 ra ld x2, 8(sp), // 恢复 sp // ... 恢复 x3-x31 addi sp, sp, 128, csrrw sp, sscratch, sp, // 恢复原 sp sret, // 返回用户态 options(noreturn) ); } } // Rust 主处理函数接收 TrapContext 引用 pub fn handle_trap(ctx: mut TrapContext) - ! { match ctx.scause.cause() { Trap::Exception(Exception::UserEnvCall) { // ecall 系统调用 let args SyscallArgs::from(ctx); let ret match args.id { SYS_WRITE sys_write(args.fd, args.buf, args.len), SYS_READ sys_read(args.fd, args.buf, args.len), SYS_YIELD sys_yield(), _ -1, }; ctx.x10 ret as usize; // x10 是返回值寄存器 } Trap::Exception(Exception::StoreFault) { // 处理缺页异常 handle_page_fault(ctx.stval, PageFault::UserWrite); } _ panic!(Unsupported trap: {:?}, ctx.scause), } // 更新 sepc准备返回 ctx.sepc 4; trap_return(ctx); }这个设计的革命性在于trap_entry汇编只做两件事——切换栈和保存寄存器所有业务逻辑包括SyscallArgs解析、系统调用分发、异常处理全部由 Rust 完成。SyscallArgs::from(ctx)的实现利用了 Rust 的Fromtrait将TrapContext中的x10-x17字段安全提取为结构体字段避免了手动索引错误。而ctx.sepc 4的写法更是直接暴露了 RISC-V 指令集的本质ecall是一条 4 字节指令sret返回后需跳过它否则会重复执行ecall导致死循环。注意trap_entry中sscratch寄存器的使用是关键技巧。RISC-V 规范规定sscratch可由软件自由使用此处用它暂存用户态sp避免在保存寄存器时破坏用户栈。这是硬件特性与软件设计的完美结合学生必须亲手调试一次sscratch未正确交换导致的栈溢出才能真正掌握。3.3 进程控制块PCBArcSpinLockTask的生命周期管理Task结构体是进程的核心载体包含寄存器上下文、页表根地址、状态Running/Ready/Blocked、父进程引用等字段。原版用static mut TASKS: [Task; MAX_TASKS]数组管理通过task_id索引存在数组越界和状态竞态风险。Rust 版本采用ArcSpinLockTask其设计哲学是进程即共享所有权的对象其生命周期由引用计数自动管理。Task定义如下pub struct Task { pub context: TrapContext, pub page_table: PageTable4, pub status: TaskStatus, pub parent: OptionArcSpinLockTask, pub children: VecArcSpinLockTask, } impl Task { pub fn new( entry_point: usize, parent: OptionArcSpinLockTask, ) - ArcSpinLockTask { let mut task Task { context: TrapContext::new(entry_point), page_table: PageTable::new(FRAME_ALLOCATOR.lock().alloc().unwrap()), status: TaskStatus::Ready, parent: parent.clone(), children: Vec::new(), }; // 映射内核代码段到新页表 task.page_table.map_range( VirtPageNum::from(VIRT_KERNEL_BASE), PhysPageNum::from(PHYS_KERNEL_BASE), KERNEL_SIZE / PAGE_SIZE, PageTableFlags::USER_ACCESSIBLE | PageTableFlags::READABLE | PageTableFlags::EXECUTABLE, ); Arc::new(SpinLock::new(task)) } }这里Arc::new(SpinLock::new(task))是核心。ArcAtomically Reference Counted提供跨线程的共享所有权SpinLock保证内部状态的互斥访问。当fork()创建子进程时代码为pub fn sys_fork() - isize { let current current_task().unwrap(); let child Task::new(current.context.sepc, Some(current.clone())); // 将子进程加入父进程的 children 列表 current.lock().children.push(child.clone()); // 将子进程加入 runqueue RUNQUEUE.lock().push(child); 0 // 返回子进程 pid }注意current.clone()调用的是Arc::clone()它只增加引用计数不复制Task数据而child.clone()同理。这确保了父子进程对彼此的引用是安全的即使父进程退出只要子进程还持有parent引用父进程的内存就不会被释放。这种设计让学生第一次体会到操作系统中的“父子关系”本质上是引用计数的拓扑结构而非简单的指针赋值。实操中常见错误是忘记在Task::new()中映射内核代码段。学生常只映射用户代码导致子进程sret返回后尝试执行用户指令但内核.text段未映射触发InstructionFetchFault。调试时需检查page_table::map_range()是否被正确调用以及VIRT_KERNEL_BASE与PHYS_KERNEL_BASE的地址转换是否准确。4. 实操全流程与关键配置说明4.1 开发环境搭建从零配置 Rust RISC-V 工具链Rust 版本的开发环境比原版 C 版本更“纯净”但也更依赖工具链的精确配置。以下是经过三届学生验证的最小可行配置以 Ubuntu 22.04 为例安装 Rustup 与 targetcurl --proto https --tlsv1.2 -sSf https://sh.rustup.rs | sh source $HOME/.cargo/env rustup target add riscv64imac-unknown-elf安装 RISC-V 工具链sudo apt install gcc-riscv64-unknown-elf binutils-riscv64-unknown-elf # 验证riscv64-unknown-elf-gcc --version 应输出 12.2.0安装 QEMU 与 OpenSBIsudo apt install qemu-system-misc wget https://github.com/riscv-software-src/opensbi/releases/download/v1.3/opensbi-1.3-qemu-fw_dynamic.bin项目目录结构标准化rcore-rust-lab2/ ├── Cargo.toml # 必须启用 no_std, no_main ├── src/ │ ├── main.rs # kernel entry point │ ├── lib.rs # 全局配置与模块声明 │ └── mm/ # 内存管理模块 │ ├── mod.rs │ ├── frame.rs # 物理页帧分配器 │ └── pagetable.rs # 页表实现 ├── linker.ld # 链接脚本指定 .text 起始地址为 0xffffffff80000000 └── Makefile # 编译与运行命令Cargo.toml的关键配置[package] name rcore-rust-kernel version 0.1.0 edition 2021 [dependencies] riscv 0.8 spin 0.9 lockfree 0.9 # 禁用 std启用 panic handler [dependencies.core] version 1.0 default-features false [profile.dev] panic abort lto false [profile.release] panic abort lto true codegen-units 1linker.ld的核心段定义SECTIONS { . 0xffffffff80000000; .text : { *(.text.entry) *(.text) . ALIGN(4K); __etext .; } .rodata : { *(.rodata) . ALIGN(4K); __erodata .; } .data : { *(.data) . ALIGN(4K); __edata .; } .bss : { *(.bss) . ALIGN(4K); __ebss .; } }这个链接脚本强制将内核代码加载到0xffffffff80000000RISC-V 64 位内核虚拟地址空间起始与VIRT_KERNEL_BASE宏定义严格一致。学生常在此处出错若linker.ld中.text起始地址设为0x80000000物理地址而代码中VIRT_KERNEL_BASE仍为0xffffffff80000000则页表映射必然失败。调试时需用riscv64-unknown-elf-objdump -d target/riscv64imac-unknown-elf/debug/rcore-rust-kernel检查_start符号地址是否匹配。4.2 编译与调试流程从cargo build到 GDB 单步追踪Rust 版本的编译命令与 C 版本不同需绕过默认的std链接# 编译为 ELF 可执行文件 cargo build --target riscv64imac-unknown-elf --release # 转换为二进制镜像供 QEMU 加载 riscv64-unknown-elf-objcopy -O binary \ target/riscv64imac-unknown-elf/release/rcore-rust-kernel \ target/riscv64imac-unknown-elf/release/kernel.bin # 启动 QEMU加载 OpenSBI 作为固件 qemu-system-riscv64 \ -machine virt \ -bios opensbi-1.3-qemu-fw_dynamic.bin \ -kernel target/riscv64imac-unknown-elf/release/kernel.bin \ -m 128M \ -s -S \ # 启用 GDB server暂停在入口点 -nographic此时 QEMU 已暂停等待 GDB 连接。新开终端# 启动 RISC-V GDB riscv64-unknown-elf-gdb \ target/riscv64imac-unknown-elf/release/rcore-rust-kernel (gdb) target remote :1234 (gdb) b _start (gdb) c (gdb) info registers (gdb) x/10i $pcGDB 调试的关键技巧符号调试确保cargo build时未启用strip否则info registers无法显示变量名。可在Cargo.toml中添加[profile.release] debug true。断点设置Rust 的#[no_mangle]函数如trap_entry可直接用函数名设断点而impl中的方法需用src/mm/pagetable.rs:42这类行号断点。内存查看x/4xw 0xffffffff80000000查看内核代码段前 16 字节x/10xg PAGE_TABLE_ROOT查看页表根地址内容。寄存器修改set $a0 0x1234可修改a0寄存器用于模拟系统调用参数。最有效的调试场景是sys_write故障当write(1, hello, 5)不输出时按以下顺序排查b sys_write断点确认是否进入p/x $a0查看fd是否为 1stdoutx/5c $a1查看buf内容是否为hellop/x $a2查看len是否为 5若以上均正确检查console::write()中uart::putchar()是否正确写入 UART 寄存器0x10000000。4.3 测试用例编写用cargo test验证内核模块Rust 版本的最大优势是可直接运行单元测试。src/mm/frame.rs的测试用例#[cfg(test)] mod tests { use super::*; #[test_case] fn test_frame_allocator() { let mut alloc BumpAllocator::new(0x8000_0000.into(), 0x8000_1000.into()); let p1 alloc.alloc().unwrap(); let p2 alloc.alloc().unwrap(); assert_eq!(p1.0, 0x8000_0000); assert_eq!(p2.0, 0x8000_1000); assert!(alloc.alloc().is_none()); // 内存池耗尽 } #[test_case] fn test_pagetable_map() { let mut pt PageTable::4::new(FRAME_ALLOCATOR.lock().alloc().unwrap()); pt.map(VirtPageNum::from(0xffff_ffff_8000_0000), PhysPageNum::from(0x8000_0000), PageTableFlags::USER_ACCESSIBLE | PageTableFlags::READABLE).unwrap(); // 验证 PTE 是否被正确设置 let pgd_index (0xffff_ffff_8000_0000 39) 0x1ff; let pgd_entry unsafe { *(pt.base_paddr.0 as *const PageTableEntry) }.0; assert_ne!(pgd_entry (1 0), 0); // VALID bit set } }运行测试cargo test --lib --target riscv64imac-unknown-elf -- --nocapture这些测试的价值在于它们不依赖 QEMU纯在宿主机上运行速度快毫秒级且能精准定位模块级错误。例如test_pagetable_map失败说明页表映射逻辑有 bug无需启动 QEMU 即可修复。学生应养成“写一个功能写一个测试”的习惯这比在 QEMU 中 printf 调试高效十倍。5. 常见问题与独家排查技巧实录5.1 典型故障速查表故障现象可能原因排查命令/步骤解决方案QEMU 启动后黑屏无任何输出satp设置过早内核代码段未映射riscv64-unknown-elf-objdump -d kernel.bin | head -20检查_start地址gdb中x/10i $pc看第一条指令确保mm::init()中先建 identity mapping再write_csr!(satp, ...)sys_write不输出但返回值正确UART 寄存器地址错误或未使能gdb中p/x *(u32*)0x10000000查看 UART 状态寄存器p/x *(u32*)0x10000004查看发送寄存器检查uart::init()是否正确写入0x10000008UART divisor和 0x100000
1. 项目概述为什么一个操作系统实验要用 Rust 重写“rust 实现 rCore lab2”——这八个字在最近两年的国内系统编程学习圈里几乎成了某种隐秘的通关暗号。它不是某个商业产品的代号也不是某家公司的内部项目而是某高校操作系统课程中一群学生在完成经典 rCore 教学操作系统第二阶段实验时主动放弃原版 C RISC-V 汇编混合实现转而用 Rust 从零重写的实践路径。我带过三届本科生做这个实验也帮某实验室的研究生调试过十几版 fork最深的体会是这不是一次简单的语言替换而是一次对“操作系统内核该长什么样”的重新校准。rCore lab2 的核心目标很明确实现一个支持多进程、地址空间隔离、系统调用接口和基础进程调度的微内核雏形。原版基于 C 语言大量依赖裸指针操作、手动内存管理、汇编嵌入如sfence.vma刷 TLB、以及宏定义堆砌的 trap 处理框架。初学者上手第一周80% 的时间花在理解“为什么这里要加 volatile”、“为什么这个结构体偏移量必须对齐到 16 字节”、“为什么sstatus.SPP要先清再设”这类底层细节上而不是思考“进程切换的本质是什么”、“页表映射如何支撑用户/内核空间分离”这些设计问题。而 Rust 的介入直接重构了整个认知链条。它不提供“更高级的抽象”反而用更严苛的规则倒逼你把所有隐含假设显性化unsafe块必须标注理由static mut被彻底禁止取而代之的是spin::Once或lockfree::AtomicCell页表项不再是usize类型的魔法数字而是封装了Level,Flags,PPN字段的PageTableEntry枚举连最基础的“获取当前 CPU 核心 ID”这种操作都必须通过PerCpu结构体的线程本地访问来完成——因为 Rust 编译器会拒绝任何可能引发数据竞争的全局可变状态。这背后的真实需求远不止“学 Rust”这么简单。它对应着三个正在加速落地的行业现实第一RISC-V 生态对内存安全内核的迫切需要——多家国产芯片厂商已明确要求 BSP 层代码通过cargo-miri内存模型验证第二教学场景中“可验证性”权重上升——lab2 的测试用例不再只检查“是否打印 hello world”而是要求cargo test --lib能通过page_table::test::map_user_page等 17 个单元测试第三工程化门槛前移——学生提交的 PR 必须包含clippy零警告、rustfmt格式合规、且cargo doc --no-deps能生成完整 API 文档。换句话说“rust 实现 rCore lab2” 已经从一门课的作业演变为检验系统级 Rust 工程能力的最小可行基准Minimum Viable Benchmark。如果你正卡在 lab1 向 lab2 过渡的节点或者正在为毕业设计寻找一个既有深度又具展示度的系统项目那么这个标题所代表的路径就是一条被反复踩实的硬核捷径。它不要求你精通 LLVM IR但必须理解const fn如何参与编译期页表构建它不强制你手写 SBI 调用但需要你读懂riscvcrate 中CSR::satp的读写封装逻辑它甚至允许你暂时跳过中断控制器 PLIC 的 Rust 化封装但一定会让你在trap::handle_trap函数里亲手把Exception::StoreFault映射到PageFault::UserWrite这个枚举变体上。这就是它的全部意义用语言的约束力把操作系统设计中最容易被忽略的“边界条件”变成编译器报错的第一行提示。2. 整体架构设计与关键决策解析2.1 为什么放弃 rCore 原版的 C 汇编混合架构rCore 原版 lab2 的技术栈选择有其历史合理性C 语言提供了对硬件寄存器的直接操控能力汇编则用于处理 CPU 特权模式切换如mret返回用户态、异常向量表跳转、以及 TLB 刷新等无法用 C 表达的原子操作。但这种组合在教学实践中暴露出三个结构性缺陷内存安全盲区不可控原版使用*mut u8强制类型转换访问页表基址寄存器satp一旦satp值构造错误如 PPN 位数超限CPU 会在下一次地址翻译时直接触发致命异常且无任何调试线索。Rust 的PhysPageNum::from_ppn()方法则在构造时就通过debug_assert!检查 PPN 有效性将错误拦截在运行前。并发模型与教学目标错位原版用static mut定义全局current_task指针配合spin_lock宏实现临界区保护。但static mut本身违反 Rust 的借用规则学生极易写出let ptr mut CURRENT_TASK; drop(ptr); *ptr new_task;这类 UB 代码。而 Rust 版本强制采用ArcSpinLockTask所有任务切换必须通过task::switch_to()接口完成该接口内部自动处理Arc::clone()和SpinLock::lock()的生命周期绑定把“谁拥有所有权”、“谁负责释放”这些概念变成编译器强制执行的契约。抽象泄漏严重原版的TrapContext结构体直接暴露x1-x31寄存器字段导致学生在实现sys_write时习惯性地写ctx.x10 write(fd, buf, len)却忽略了x10在 RISC-V ABI 中实际是返回值寄存器而参数应从x10-x17传入。Rust 版本则定义SyscallArgs { fd: usize, buf: *const u8, len: usize }并通过impl FromTrapContext for SyscallArgs实现安全转换把 ABI 细节封装在 trait 实现里使用者只需关注语义。因此Rust 版本的架构设计本质上是一次“防御性重构”它不追求性能极致事实上开启lto true后Rust 版本在 QEMU 上的 syscall 开销比 C 版本高约 8%而是把“防止学生写出不可维护的内核代码”作为首要目标。这决定了所有后续技术选型——从内存分配器到中断处理——都必须服务于这个核心原则。2.2 内存管理模块为何选择 bump allocator 而非 slablab2 要求实现用户进程的地址空间隔离这意味着内核必须能动态分配物理页帧Physical Page Frame并建立页表映射。原版 rCore 使用linked_list_allocator这是一个通用型堆分配器支持任意大小内存块的alloc/dealloc。但在教学场景中它带来了两个严重干扰项碎片化问题掩盖设计本质学生在调试fork()时常因alloc()返回的物理页地址不连续误以为是页表映射逻辑错误实则只是分配器碎片导致。而 bump allocator 总是返回递增地址让“物理页分配”与“虚拟地址映射”的对应关系一目了然。dealloc 语义与内核生命周期冲突内核中绝大多数内存如进程控制块 PCB、内核栈一旦分配生命周期即与进程绑定不存在运行时free()的需求。linked_list_allocator的dealloc接口反而诱导学生去思考“何时释放 PCB”偏离了 lab2 “理解地址空间生命周期”的核心目标。Rust 版本因此采用定制化的BumpAllocator其设计极其精简pub struct BumpAllocator { next_free: PhysPageNum, end: PhysPageNum, } impl BumpAllocator { pub const fn new(start: PhysPageNum, end: PhysPageNum) - Self { Self { next_free: start, end } } pub fn alloc(mut self) - OptionPhysPageNum { if self.next_free self.end { let ppn self.next_free; self.next_free self.next_free 1; Some(ppn) } else { None } } }这个实现的关键在于const fn new()—— 它允许在编译期就确定内存池范围例如BUMP_ALLOCATOR.init(BumpAllocator::new(0x8000_0000.into(), 0x8001_0000.into()))把 64MB 物理内存0x80000000–0x80010000划为内核堆。所有alloc()调用都转化为对next_free的原子递增无锁、无分支、无函数调用开销。更重要的是它让学生直观看到内核内存不是“无限资源”而是一段被精确划定的物理地址区间超出即 OOM。当fork()失败时错误原因不再是模糊的“分配失败”而是清晰的BumpAllocator::alloc() returned None at line 42直指内存池耗尽这一根本矛盾。提示BumpAllocator 的局限性在 lab3 才会暴露需支持用户态堆 malloc因此 lab2 选用它是精准匹配教学目标的“够用就好”策略而非技术妥协。2.3 进程调度器为何采用 runqueue FIFO 而非 CFSrCore lab2 的调度需求非常朴素能启动多个用户进程如init,sh,ls保证它们轮流获得 CPU 时间片且在进程阻塞如等待键盘输入时能切换到其他就绪进程。原版使用基于优先级的队列但优先级数值的设定缺乏教学依据学生常随意赋值task.priority 5导致调度行为不可预测。Rust 版本改用纯 FIFO 的RunQueue其核心结构如下pub struct RunQueue { queue: VecArcSpinLockTask, } impl RunQueue { pub fn push(mut self, task: ArcSpinLockTask) { self.queue.push(task); } pub fn pop(mut self) - OptionArcSpinLockTask { self.queue.pop() } pub fn tick(mut self) { if let Some(task) self.pop() { self.push(task); } } }这个设计的精妙之处在于tick()方法每次时钟中断触发时调度器将队首任务移到队尾实现天然的时间片轮转。学生无需理解红黑树或虚拟运行时间vruntime只需记住“队列是环形的tick 就是转一圈”。当实现sys_yield()系统调用时代码简洁到令人惊讶pub fn sys_yield() - isize { // 将当前任务从 runqueue 移除并放回队尾 let current current_task().unwrap(); RUNQUEUE.lock().remove(current); RUNQUEUE.lock().push(current); 0 }这里RUNQUEUE.lock().remove()的实现利用了Vec::retain()的稳定迭代特性确保在遍历过程中安全删除元素。整个调度逻辑不到 20 行代码却完整覆盖了 lab2 所有调度需求。它传递给学生的是一种设计哲学在教学系统中可理解性永远优于工程完备性一个能被一行注释说清的算法比一个需要三页论文解释的优化方案更有价值。3. 核心模块实现详解与实操要点3.1 页表管理从Satp寄存器到四级页表遍历RISC-V 64 采用四级页表PGD → PUD → PMD → PTE每个页表项PTE占 8 字节包含PPN物理页号、R/W/X权限位、U用户态访问位等字段。原版 rCore 用宏定义PAGE_TABLE_LEVELS 4和位运算硬编码所有偏移学生需手动计算pgd_index(vaddr) (vaddr 39) 0x1ff极易出错。Rust 版本将页表抽象为泛型结构体PageTableL其中L是页表级别const LEVEL: usize 4。关键实现在PageTable::map()方法implconst LEVEL: usize PageTableLEVEL { pub fn map( mut self, vpn: VirtPageNum, ppn: PhysPageNum, flags: PageTableFlags, ) - Result(), static str { // 1. 计算当前层级的索引 let index vpn.index(LEVEL); // 2. 获取对应页表项 let pte_addr self.base_paddr index * core::mem::size_of::PageTableEntry(); let pte_ptr pte_addr.as_mut_ptr::PageTableEntry(); let pte unsafe { mut *pte_ptr }; // 3. 若为中间页表且未存在分配新页帧 if LEVEL 1 !pte.is_valid() { let new_pt FRAME_ALLOCATOR.lock().alloc().ok_or(Out of memory)?; pte.set_ppn(new_pt); pte.set_flags(PageTableFlags::VALID); // 递归初始化下级页表 let next_pt PageTable::{ LEVEL - 1 }::new(new_pt); next_pt.init_zero(); } // 4. 若为最后一级PTE设置目标映射 if LEVEL 1 { pte.set_ppn(ppn); pte.set_flags(flags | PageTableFlags::VALID); } else { // 否则递归映射到下级 let next_pt PageTable::{ LEVEL - 1 }::from_ppn(pte.ppn()); next_pt.map(vpn, ppn, flags)?; } Ok(()) } }这段代码的教学价值极高。首先vpn.index(LEVEL)封装了所有位运算细节学生只需知道“第 4 级用最高 9 位”即可其次pte.is_valid()和pte.set_flags()将位操作封装为方法调用避免了pte.bits | 1 0这类易错写法最关键的是递归逻辑当LEVEL 1时若目标 PTE 无效则分配新页帧并递归初始化下级页表。这让学生直观理解“页表是树状结构”而map()就是 DFS 遍历。实操中最大的坑在于satp寄存器的设置时机。很多学生在kernel_main()中初始化完页表后立即调用write_csr!(satp, ...)结果内核崩溃。原因在于satp切换后CPU 会立即用新页表翻译后续指令地址而此时内核代码段.text很可能尚未被映射到新页表中正确做法是先用 identity mapping物理地址虚拟地址构建一个临时页表覆盖内核代码段在此页表下执行write_csr!(satp, ...)切换再在新页表中建立真正的内核虚拟地址映射如0xffffffff80000000→0x80000000最后刷新 TLBasm!(sfence.vma, options(nomem, nostack))。这个过程被封装在mm::init()函数中学生只需调用mm::init()但必须理解其四步拆解逻辑否则无法调试页表相关故障。3.2 系统调用分发ecall异常处理的 Rust 化重构RISC-V 中用户态程序通过ecall指令触发系统调用CPU 自动跳转到stvec寄存器指向的 trap 处理入口。原版 rCore 用汇编编写trap_entry保存所有寄存器到栈再调用 C 函数handle_trap()后者根据scause寄存器值分发到sys_read、sys_write等函数。这种设计导致两个问题一是寄存器保存/恢复逻辑与业务逻辑混杂二是handle_trap()需要手动解析sepc、stval等寄存器易出错。Rust 版本采用完全不同的思路让 Rust 编译器接管寄存器管理用#[naked]函数实现最小化汇编胶水其余全部 Rust 实现。核心代码如下// 汇编胶水仅做必要寄存器保存 #[naked] #[no_mangle] pub extern C fn trap_entry() { unsafe { asm!( csrrw t0, sscratch, sp, // 交换 sp 与 sscratch csrrw sp, sscratch, t0, // 将原 sp 存入 sscratch addi sp, sp, -128, // 为 TrapContext 分配栈空间 sd x1, 0(sp), // 保存 ra sd x2, 8(sp), // 保存 sp // ... 保存 x3-x31 jal handle_trap, // 调用 Rust 函数 ld x1, 0(sp), // 恢复 ra ld x2, 8(sp), // 恢复 sp // ... 恢复 x3-x31 addi sp, sp, 128, csrrw sp, sscratch, sp, // 恢复原 sp sret, // 返回用户态 options(noreturn) ); } } // Rust 主处理函数接收 TrapContext 引用 pub fn handle_trap(ctx: mut TrapContext) - ! { match ctx.scause.cause() { Trap::Exception(Exception::UserEnvCall) { // ecall 系统调用 let args SyscallArgs::from(ctx); let ret match args.id { SYS_WRITE sys_write(args.fd, args.buf, args.len), SYS_READ sys_read(args.fd, args.buf, args.len), SYS_YIELD sys_yield(), _ -1, }; ctx.x10 ret as usize; // x10 是返回值寄存器 } Trap::Exception(Exception::StoreFault) { // 处理缺页异常 handle_page_fault(ctx.stval, PageFault::UserWrite); } _ panic!(Unsupported trap: {:?}, ctx.scause), } // 更新 sepc准备返回 ctx.sepc 4; trap_return(ctx); }这个设计的革命性在于trap_entry汇编只做两件事——切换栈和保存寄存器所有业务逻辑包括SyscallArgs解析、系统调用分发、异常处理全部由 Rust 完成。SyscallArgs::from(ctx)的实现利用了 Rust 的Fromtrait将TrapContext中的x10-x17字段安全提取为结构体字段避免了手动索引错误。而ctx.sepc 4的写法更是直接暴露了 RISC-V 指令集的本质ecall是一条 4 字节指令sret返回后需跳过它否则会重复执行ecall导致死循环。注意trap_entry中sscratch寄存器的使用是关键技巧。RISC-V 规范规定sscratch可由软件自由使用此处用它暂存用户态sp避免在保存寄存器时破坏用户栈。这是硬件特性与软件设计的完美结合学生必须亲手调试一次sscratch未正确交换导致的栈溢出才能真正掌握。3.3 进程控制块PCBArcSpinLockTask的生命周期管理Task结构体是进程的核心载体包含寄存器上下文、页表根地址、状态Running/Ready/Blocked、父进程引用等字段。原版用static mut TASKS: [Task; MAX_TASKS]数组管理通过task_id索引存在数组越界和状态竞态风险。Rust 版本采用ArcSpinLockTask其设计哲学是进程即共享所有权的对象其生命周期由引用计数自动管理。Task定义如下pub struct Task { pub context: TrapContext, pub page_table: PageTable4, pub status: TaskStatus, pub parent: OptionArcSpinLockTask, pub children: VecArcSpinLockTask, } impl Task { pub fn new( entry_point: usize, parent: OptionArcSpinLockTask, ) - ArcSpinLockTask { let mut task Task { context: TrapContext::new(entry_point), page_table: PageTable::new(FRAME_ALLOCATOR.lock().alloc().unwrap()), status: TaskStatus::Ready, parent: parent.clone(), children: Vec::new(), }; // 映射内核代码段到新页表 task.page_table.map_range( VirtPageNum::from(VIRT_KERNEL_BASE), PhysPageNum::from(PHYS_KERNEL_BASE), KERNEL_SIZE / PAGE_SIZE, PageTableFlags::USER_ACCESSIBLE | PageTableFlags::READABLE | PageTableFlags::EXECUTABLE, ); Arc::new(SpinLock::new(task)) } }这里Arc::new(SpinLock::new(task))是核心。ArcAtomically Reference Counted提供跨线程的共享所有权SpinLock保证内部状态的互斥访问。当fork()创建子进程时代码为pub fn sys_fork() - isize { let current current_task().unwrap(); let child Task::new(current.context.sepc, Some(current.clone())); // 将子进程加入父进程的 children 列表 current.lock().children.push(child.clone()); // 将子进程加入 runqueue RUNQUEUE.lock().push(child); 0 // 返回子进程 pid }注意current.clone()调用的是Arc::clone()它只增加引用计数不复制Task数据而child.clone()同理。这确保了父子进程对彼此的引用是安全的即使父进程退出只要子进程还持有parent引用父进程的内存就不会被释放。这种设计让学生第一次体会到操作系统中的“父子关系”本质上是引用计数的拓扑结构而非简单的指针赋值。实操中常见错误是忘记在Task::new()中映射内核代码段。学生常只映射用户代码导致子进程sret返回后尝试执行用户指令但内核.text段未映射触发InstructionFetchFault。调试时需检查page_table::map_range()是否被正确调用以及VIRT_KERNEL_BASE与PHYS_KERNEL_BASE的地址转换是否准确。4. 实操全流程与关键配置说明4.1 开发环境搭建从零配置 Rust RISC-V 工具链Rust 版本的开发环境比原版 C 版本更“纯净”但也更依赖工具链的精确配置。以下是经过三届学生验证的最小可行配置以 Ubuntu 22.04 为例安装 Rustup 与 targetcurl --proto https --tlsv1.2 -sSf https://sh.rustup.rs | sh source $HOME/.cargo/env rustup target add riscv64imac-unknown-elf安装 RISC-V 工具链sudo apt install gcc-riscv64-unknown-elf binutils-riscv64-unknown-elf # 验证riscv64-unknown-elf-gcc --version 应输出 12.2.0安装 QEMU 与 OpenSBIsudo apt install qemu-system-misc wget https://github.com/riscv-software-src/opensbi/releases/download/v1.3/opensbi-1.3-qemu-fw_dynamic.bin项目目录结构标准化rcore-rust-lab2/ ├── Cargo.toml # 必须启用 no_std, no_main ├── src/ │ ├── main.rs # kernel entry point │ ├── lib.rs # 全局配置与模块声明 │ └── mm/ # 内存管理模块 │ ├── mod.rs │ ├── frame.rs # 物理页帧分配器 │ └── pagetable.rs # 页表实现 ├── linker.ld # 链接脚本指定 .text 起始地址为 0xffffffff80000000 └── Makefile # 编译与运行命令Cargo.toml的关键配置[package] name rcore-rust-kernel version 0.1.0 edition 2021 [dependencies] riscv 0.8 spin 0.9 lockfree 0.9 # 禁用 std启用 panic handler [dependencies.core] version 1.0 default-features false [profile.dev] panic abort lto false [profile.release] panic abort lto true codegen-units 1linker.ld的核心段定义SECTIONS { . 0xffffffff80000000; .text : { *(.text.entry) *(.text) . ALIGN(4K); __etext .; } .rodata : { *(.rodata) . ALIGN(4K); __erodata .; } .data : { *(.data) . ALIGN(4K); __edata .; } .bss : { *(.bss) . ALIGN(4K); __ebss .; } }这个链接脚本强制将内核代码加载到0xffffffff80000000RISC-V 64 位内核虚拟地址空间起始与VIRT_KERNEL_BASE宏定义严格一致。学生常在此处出错若linker.ld中.text起始地址设为0x80000000物理地址而代码中VIRT_KERNEL_BASE仍为0xffffffff80000000则页表映射必然失败。调试时需用riscv64-unknown-elf-objdump -d target/riscv64imac-unknown-elf/debug/rcore-rust-kernel检查_start符号地址是否匹配。4.2 编译与调试流程从cargo build到 GDB 单步追踪Rust 版本的编译命令与 C 版本不同需绕过默认的std链接# 编译为 ELF 可执行文件 cargo build --target riscv64imac-unknown-elf --release # 转换为二进制镜像供 QEMU 加载 riscv64-unknown-elf-objcopy -O binary \ target/riscv64imac-unknown-elf/release/rcore-rust-kernel \ target/riscv64imac-unknown-elf/release/kernel.bin # 启动 QEMU加载 OpenSBI 作为固件 qemu-system-riscv64 \ -machine virt \ -bios opensbi-1.3-qemu-fw_dynamic.bin \ -kernel target/riscv64imac-unknown-elf/release/kernel.bin \ -m 128M \ -s -S \ # 启用 GDB server暂停在入口点 -nographic此时 QEMU 已暂停等待 GDB 连接。新开终端# 启动 RISC-V GDB riscv64-unknown-elf-gdb \ target/riscv64imac-unknown-elf/release/rcore-rust-kernel (gdb) target remote :1234 (gdb) b _start (gdb) c (gdb) info registers (gdb) x/10i $pcGDB 调试的关键技巧符号调试确保cargo build时未启用strip否则info registers无法显示变量名。可在Cargo.toml中添加[profile.release] debug true。断点设置Rust 的#[no_mangle]函数如trap_entry可直接用函数名设断点而impl中的方法需用src/mm/pagetable.rs:42这类行号断点。内存查看x/4xw 0xffffffff80000000查看内核代码段前 16 字节x/10xg PAGE_TABLE_ROOT查看页表根地址内容。寄存器修改set $a0 0x1234可修改a0寄存器用于模拟系统调用参数。最有效的调试场景是sys_write故障当write(1, hello, 5)不输出时按以下顺序排查b sys_write断点确认是否进入p/x $a0查看fd是否为 1stdoutx/5c $a1查看buf内容是否为hellop/x $a2查看len是否为 5若以上均正确检查console::write()中uart::putchar()是否正确写入 UART 寄存器0x10000000。4.3 测试用例编写用cargo test验证内核模块Rust 版本的最大优势是可直接运行单元测试。src/mm/frame.rs的测试用例#[cfg(test)] mod tests { use super::*; #[test_case] fn test_frame_allocator() { let mut alloc BumpAllocator::new(0x8000_0000.into(), 0x8000_1000.into()); let p1 alloc.alloc().unwrap(); let p2 alloc.alloc().unwrap(); assert_eq!(p1.0, 0x8000_0000); assert_eq!(p2.0, 0x8000_1000); assert!(alloc.alloc().is_none()); // 内存池耗尽 } #[test_case] fn test_pagetable_map() { let mut pt PageTable::4::new(FRAME_ALLOCATOR.lock().alloc().unwrap()); pt.map(VirtPageNum::from(0xffff_ffff_8000_0000), PhysPageNum::from(0x8000_0000), PageTableFlags::USER_ACCESSIBLE | PageTableFlags::READABLE).unwrap(); // 验证 PTE 是否被正确设置 let pgd_index (0xffff_ffff_8000_0000 39) 0x1ff; let pgd_entry unsafe { *(pt.base_paddr.0 as *const PageTableEntry) }.0; assert_ne!(pgd_entry (1 0), 0); // VALID bit set } }运行测试cargo test --lib --target riscv64imac-unknown-elf -- --nocapture这些测试的价值在于它们不依赖 QEMU纯在宿主机上运行速度快毫秒级且能精准定位模块级错误。例如test_pagetable_map失败说明页表映射逻辑有 bug无需启动 QEMU 即可修复。学生应养成“写一个功能写一个测试”的习惯这比在 QEMU 中 printf 调试高效十倍。5. 常见问题与独家排查技巧实录5.1 典型故障速查表故障现象可能原因排查命令/步骤解决方案QEMU 启动后黑屏无任何输出satp设置过早内核代码段未映射riscv64-unknown-elf-objdump -d kernel.bin | head -20检查_start地址gdb中x/10i $pc看第一条指令确保mm::init()中先建 identity mapping再write_csr!(satp, ...)sys_write不输出但返回值正确UART 寄存器地址错误或未使能gdb中p/x *(u32*)0x10000000查看 UART 状态寄存器p/x *(u32*)0x10000004查看发送寄存器检查uart::init()是否正确写入0x10000008UART divisor和 0x100000
