文档教程技术博客操作系统【免费下载链接】blog_osWriting an OS in Rust项目地址https://gitcode.com/GitHub_Trending/bl/blog_os点击查看免费下载本文基于《Writing an OS in Rust》系列第二篇文章blog/content/edition-2/posts/02-minimal-rust-kernel/index.zh-CN.md讲解如何在前一篇独立式 Rust 可执行程序的基础上构建一个面向 x86_64 裸机环境的最小化 64 位内核。你将理解从主板固件到引导程序的完整启动链路亲手编写目标配置清单target specification、处理corecrate 的交叉编译并最终通过bootimage工具生成一个能打印 Hello World! 的可引导磁盘映像在 QEMU 与真机上运行。计算机是如何启动的BIOS、引导程序与内核当我们按下电源键CPU 首先执行的是存储在主板只读存储器ROM中的固件代码。固件负责执行加电自检power-on self test检测硬件是否正常探测可用内存available RAM预初始化 CPU 与各类外设查找可引导的存储介质bootable disk并把控制权交给其中的内核。在 x86 架构上存在两种固件标准BIOSBasic Input/Output System与UEFIUnified Extensible Firmware Interface。BIOS 虽然古老过时但实现简单从 1980 年代起就被所有 x86 设备支持UEFI 更加现代、功能更全但搭建过程复杂得多。本教程目前仅提供 BIOS 引导支持UEFI 支持仍在规划中。BIOS 引导的完整流程几乎所有的 x86 设备都支持 BIOS 引导包括那些通过模拟 BIOSemulated BIOS向后兼容的新型 UEFI 机器。这带来一个好处无论硬件新旧你都可以使用同一套引导逻辑但代价是 CPU 必须先进入 16 位兼容的实模式real mode好让 1980 年代的古老引导固件能够继续工作。BIOS 引导的过程可以拆解为如下几个阶段主板闪存中的 BIOS 固件被加载并执行自检与硬件初始化BIOS 查找可引导磁盘找到后把控制权交给磁盘开头一段512 字节的引导程序bootloader由于大多数引导程序都超过 512 字节它们通常被切分为第一阶段引导程序恰好 512 字节、位于介质开头负责加载第二阶段第二阶段引导程序存储在其他位置、长度不限由第一阶段加载进内存。引导程序需要完成三项核心工作确定内核映像在磁盘上的位置并加载进内存把 CPU 从 16 位实模式切换到 32 位保护模式protected mode再切换到 64 位长模式long mode——只有进入长模式全部 64 位寄存器与完整主内存才可用从 BIOS 查询特定信息如内存映射表memory map并传递给操作系统内核。自己编写引导程序并不轻松它需要汇编语言还要执行大量意图不明显的步骤比如把这个魔术数字写到那个处理器寄存器。因此本教程不讲解如何编写引导程序而是使用 bootimage 工具为内核自动准备引导程序。为什么不用 Multiboot 标准与 GRUB1995 年自由软件基金会Free Software Foundation颁布了开源的Multiboot引导标准定义了引导程序与操作系统之间的统一接口任何适配 Multiboot 的引导程序都可以加载任何同样适配 Multiboot 的操作系统。GNU GRUB 是最热门的 Linux 引导程序也是参考实现。要让内核适配 Multiboot只需在内核文件开头插入一段Multiboot 头Multiboot header即可。但 GRUB 与 Multiboot 标准存在一些可预知的问题只支持 32 位保护模式引导之后仍需自行配置 CPU 切换到 64 位长模式以简化引导程序而非内核为目标例如内核必须以调整过的默认页长度链接否则 GRUB 找不到 Multiboot 头又例如传给内核的引导信息包含大量与架构相关的数据结构缺少清晰的抽象层文档匮乏GRUB 与 Multiboot 标准都没有被详细解释阅读门槛高构建环境受限要生成可引导磁盘映像必须在宿主机安装 GRUB这让 Windows 或 macOS 上的内核开发变得困难。基于这些原因本系列决定不使用 GRUB 或 Multiboot 标准bootimage 工具已规划支持 Multiboot。如果对 Multiboot 内核感兴趣可以查阅初版第一版文档。UEFI截至本文撰写时本系列尚未提供 UEFI 教程但已列入计划当前bootloadercrate 也暂不支持 UEFI 引导。目标一个打印 Hello World! 的最小内核在上一篇文章中我们用cargo构建了一个独立freestanding二进制程序但它仍然面向特定操作系统因为cargo默认是为宿主系统host system即当前运行的系统编译不同平台需要不同的入口点名称与编译指令。这对内核没有意义——内核不应运行在另一个操作系统之上它本身就是操作系统。因此我们必须为明确的目标系统target system编译。我们的目标很清晰创建一个可引导的磁盘映像启动后在屏幕上打印一行 Hello World!。安装 Nightly RustRust 有三个发行频道stable、beta 与 nightly。构建操作系统需要一些仅 nightly 提供的实验性功能因此必须安装 nightly 版本的 Rust。推荐使用 rustup 管理 Rust 安装它允许同时安装三个频道的编译器并轻松更新。有两种方式让当前目录使用 nightly# 方式一为当前目录指定 nightly rustup override add nightly # 方式二在项目根目录创建 rust-toolchain 文件内容为 nightly echo nightly rust-toolchain验证方式运行rustc --version版本号末尾应包含-nightly。nightly 编译器允许通过文件顶部的特性标签feature flag启用实验性功能。例如启用实验性的内联汇编asm!宏#![feature(asm)]注意这些实验性功能不稳定未来 Rust 版本可能随时修改或移除它们且无警告应只在绝对必要时使用。目标配置清单Target Specificationcargo通过--target参数支持不同目标系统目标由目标三元组target triple描述它涵盖 CPU 架构、平台供应者、操作系统与应用程序二进制接口ABI。例如x86_64-unknown-linux-gnu表示x86_64架构 CPU、无明确供应者、Linux 系统、GNU 风格 ABI。Rust 官方支持许多三元组如 Android 的arm-linux-androideabi、WebAssembly 的wasm32-unknown-unknown等。但我们的内核要求特殊配置如没有底层操作系统现有目标都不满足。幸运的是Rust 允许通过一个JSON 文件定义自己的目标系统这个文件就是目标配置清单target specification。作为参照描述x86_64-unknown-linux-gnu的清单大致如下{ llvm-target: x86_64-unknown-linux-gnu, data-layout: e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128, arch: x86_64, target-endian: little, target-pointer-width: 64, target-c-int-width: 32, os: linux, executables: true, linker-flavor: gcc, pre-link-args: [-m64], morestack: false }清单中的字段分三类LLVM 所需如data-layout定义各整数、浮点与指针类型的长度LLVM 据此生成目标平台代码Rust 条件编译所需如target-pointer-width定义 crate 的构建方式如pre-link-args指定传给链接器的参数。编写 x86_64 裸机目标清单我们的内核面向x86_64架构与上面的例子高度相似。在项目根目录创建x86_64-blog_os.json文件名可自选先写入公共内容{ llvm-target: x86_64-unknown-none, data-layout: e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128, arch: x86_64, target-endian: little, target-pointer-width: 64, target-c-int-width: 32, os: none, executables: true }注意因为要在裸机bare metal上运行llvm-target与os字段的值都已改为none。接下来补充编译相关的配置项linker-flavor: ld.lld, linker: rust-lld,这里不使用平台默认链接器它可能不支持 Linux 目标而是使用随 Rust 一起打包发布的跨平台LLD 链接器。panic-strategy: abort,该配置指定目标不支持 panic 时的栈展开stack unwinding因此 panic 时直接中止abort on panic。其效果等同于Cargo.toml中的panic abort选项所以可以移除后者。需要特别说明的是与Cargo.toml选项不同这个目标选项在后续重新编译core库时同样生效因此务必保留。disable-redzone: true,编写内核迟早要处理中断。为了安全地处理中断必须禁用名为红区red zone的栈指针优化否则它可能导致栈被破坏。细节见仓库中的短文禁用红区红区是 System V ABI 提供的优化允许函数在不修改栈指针的前提下临时使用栈帧下方 128 字节当异常或硬件中断发生时CPU 会覆盖红区数据而被中断的函数仍引用这些数据导致难以追踪的错误往往要排查数周因此内核必须从一开始就禁用。features: -mmx,-sse,soft-float,features字段用于启用/禁用目标CPU 特征前缀-表示禁用前缀表示启用。这里禁用mmx与sse启用soft-float。为什么禁用 SIMDmmx与sse决定是否支持单指令多数据流SIMD指令这类指令通常能显著提升程序性能。但在内核中使用庞大的 SIMD 寄存器会带来严重的性能问题内核在继续被中断的程序前必须把所有寄存器恢复到原状也就是说每个系统调用或硬件中断都要把完整的 SIMD 状态存入主内存。SIMD 状态可达 512~1600 字节而中断又频繁发生这些额外的保存/恢复操作会显著拖慢系统。因此我们为内核禁用 SIMD注意并不影响运行在内核之上的应用程序使用 SIMD。为什么需要soft-float禁用 SIMD 引出一个问题x86_64架构的浮点运算默认依赖 SIMD 寄存器。解决办法是启用soft-float特征用基于普通整数的软件函数模拟全部浮点运算会牺牲一点性能。更详细的背景见仓库短文禁用 SIMD其中梳理了 MMXmm0~mm7八个 64 位寄存器映射自 x87 浮点单元、SSExmm0~xmm15十六个 128 位寄存器与 AVXymm0~ymm15十六个 256 位寄存器三代 SIMD 标准的演进。另外要注意features字符串中各标志之间不能有空格否则 LLVM 无法解析。完整目标配置清单将上述配置项整合最终的x86_64-blog_os.json如下{ llvm-target: x86_64-unknown-none, data-layout: e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128, arch: x86_64, target-endian: little, target-pointer-width: 64, target-c-int-width: 32, os: none, executables: true, linker-flavor: ld.lld, linker: rust-lld, panic-strategy: abort, disable-redzone: true, features: -mmx,-sse,soft-float }编译内核ld.lld链接器风格会让 LLVM 以 Linux 风格约定-flavor gnu编译这意味着入口点必须命名为_start。无论宿主机是哪个操作系统入口点都叫_start上一篇文章中的 Windows/macOS 入口点不应保留。src/main.rs内容如下// src/main.rs #![no_std] // 不链接 Rust 标准库 #![no_main] // 禁用所有 Rust 层级的入口点 use core::panic::PanicInfo; /// 这个函数将在 panic 时被调用 #[panic_handler] fn panic(_info: PanicInfo) - ! { loop {} } #[no_mangle] // 不重整函数名 pub extern C fn _start() - ! { // 因为编译器会寻找一个名为 _start 的函数所以这个函数就是入口点 loop {} }这段代码延续了上一篇的成果#![no_std]不链接标准库在上一篇中它带来了panic_handler缺失、eh_personalitylanguage item 缺失等问题#![no_main]跳过crt0→lang_start→main的入口链直接覆盖操作系统入口点#[panic_handler]定义 panic 时的行为目前只是无限循环#[no_mangle]阻止编译器重整_start的函数名使链接器能按默认入口名找到它。现在尝试编译 cargo build --target x86_64-blog_os.json error[E0463]: cant find crate for core编译失败了编译器找不到corecrate。core库包含Result、Option、迭代器等 Rust 基础类型会被隐式链接到所有no_stdcrate。问题是core以预编译库的形式随 Rust 编译器分发只对受支持的宿主系统有效对我们的自定义目标无效。要为其他目标编译代码必须先为这些目标重新编译core。build-std选项按需重编译标准库cargo 的build-std特性允许按需重新编译core等标准库 crate而不是使用 Rust 安装自带的预编译版本。该特性很新且尚未完全完成被标记为 unstable仅在 nightly 编译器上可用。启用方式创建.cargo/config.toml.cargo目录与src目录同级# in .cargo/config.toml [unstable] build-std [core, compiler_builtins]该配置告知 cargo 重新编译core与compiler_builtins两个 crate——后者是core的必要依赖。重新编译需要 Rust 源码用以下命令安装rustup component add rust-src注意unstable.build-std配置项要求 Rust nightly 版本不早于 2020-07-15。配置完成并安装rust-src后重新编译 cargo build --target x86_64-blog_os.json Compiling core v0.0.0 (/…/rust/src/libcore) Compiling rustc-std-workspace-core v1.99.0 (/…/rust/src/tools/rustc-std-workspace-core) Compiling compiler_builtins v0.1.32 Compiling blog_os v0.1.0 (/…/blog_os) Finished dev [unoptimized debuginfo] target(s) in 0.29 secs可以看到cargo build现在为自定义目标重新编译了core、rustc-std-workspace-corecompiler_builtins的依赖与compiler_builtins。内存相关内置函数Memory-Related IntrinsicsRust 编译器假定所有系统都具备一组内置函数。大部分由刚重编译的compiler_builtinscrate 提供但其中一些内存相关函数默认被禁用——因为它们通常由系统的 C 库提供。这些函数包括memset把内存块中所有字节设为给定值memcpy把一块内存的数据拷贝到另一块memcmp比较两块内存的数据。当前内核暂时用不到它们但一旦代码变复杂如拷贝结构体就会需要。由于内核无法链接操作系统的 C 库必须另想办法。一个直观的思路是自己实现memset等函数并加上#[no_mangle]属性避免编译时被自动重命名。但这很危险底层函数最细微的错误也会导致未定义行为。例如用for循环实现memcpy可能引发无限递归——因为for循环会隐式调用IntoIterator::into_itertrait 方法而后者可能再次调用memcpy。因此更可靠的做法是复用经过良好测试的既存实现。幸运的是compiler_builtins本来就包含所有所需函数的实现只是为避免与 C 库实现冲突而默认禁用。将 cargo 的build-std-features配置为[compiler-builtins-mem]即可启用。该特性既可以-Z命令行参数传入也可以写在.cargo/config.toml的unstable配置表中——我们总是需要它所以用配置文件更合理# in .cargo/config.toml [unstable] build-std-features [compiler-builtins-mem] build-std [core, compiler_builtins]compiler-builtins-mem特性引入较晚需要 Rust nightly 不早于 2020-09-30。在底层该标志启用了compiler_builtinscrate 的mem特性效果是其中的memcpy等实现被加上#[no_mangle]属性从而对链接器可见。经过这些修改内核已具备全部编译所需的函数可以继续完善代码。设置默认编译目标每次cargo build都传--target很麻烦可以在.cargo/config.toml中覆写默认目标# in .cargo/config.toml [build] target x86_64-blog_os.json这样cargo在没有显式--target参数时使用x86_64-blog_os.json只需一句cargo build即可编译到目标平台。至此我们能用cargo build完成编译但_start函数体仍然是空循环是时候向屏幕输出点什么了。向屏幕打印字符写入 VGA 字符缓冲区当前阶段向屏幕打印文字最简单的途径是VGA 字符缓冲区VGA text buffer一段映射到 VGA 硬件、包含屏幕显示内容的特殊内存区域。它通常能存储25 行 × 80 列 2000 个字符单元character cell每个单元显示一个 ASCII 字符并可设置该字符的前景色与背景色。关于 VGA 缓冲区的详细内存布局会在下一篇VGA 字符模式中展开这里只需知道两个要点缓冲区地址为0xb8000每个字符单元包含一个ASCII 码字节和一个颜色字节。实现代码如下static HELLO: [u8] bHello World!; #[no_mangle] pub extern C fn _start() - ! { let vga_buffer 0xb8000 as *mut u8; for (i, byte) in HELLO.iter().enumerate() { unsafe { *vga_buffer.offset(i as isize * 2) byte; *vga_buffer.offset(i as isize * 2 1) 0xb; } } loop {} }逐段解读定义名为HELLO的静态变量类型为字节字符串byte string切片把整数0xb8000转换为裸指针raw pointer*mut u8用iter()迭代HELLO的每个字节配合enumerate()取得序号i在循环体内用offset偏移裸指针并解引用写入第i * 2个字节写 ASCII 字符第i * 2 1个字节写颜色字节——0xb代表淡青色light cyan。关于unsafe的正确态度所有裸指针内存操作都被包在unsafe语句块中因为编译器无法证明裸指针有效裸指针可能指向任何内存位置直接解引用写入可能破坏正常数据。使用unsafe块相当于程序员向编译器保证块内操作有效。需要澄清的是unsafe块不会关闭Rust 的安全检查它只额外允许你做少数几件受限的事情。必须强调肆意使用unsafe并不是 Rust 编程的一贯方式。缺乏经验时直接在unsafe块内操作裸指针极易出错比如不小心写出缓冲区边界。所以应该把unsafe的使用降到最低用 Rust 的能力把不安全操作封装成安全抽象——例如创建一个 VGA 缓冲区类型把所有不安全语句封装在内使外部代码无法写出破坏内存安全的操作。这正是下一篇文章要做的事。启动内核创建引导映像有了能打印字符的可执行程序接下来把它跑起来。分两步先把编译好的内核与引导程序链接成可引导磁盘映像再在 QEMU 虚拟机中运行或通过 U 盘在真机上运行。使用 bootloader crate 与 bootimage 工具要将可执行程序转换为可引导磁盘映像必须把它与引导程序链接。引导程序负责初始化 CPU 并加载内核。我们不自研引导程序而是使用 bootloader crate——它完全基于 Rust 代码与内联汇编实现了一个五脏俱全的 BIOS 引导程序无任何 C 依赖。在Cargo.toml中添加依赖# in Cargo.toml [dependencies] bootloader 0.9注意本教程仅兼容bootloader v0.9。较新的版本使用不同的构建系统按本文步骤会构建失败。仅添加依赖还不够需要在编译完成后把内核与引导程序组合而 cargo 原生不支持编译后追加步骤。解决方案是bootimage工具——它先编译内核再把内核与引导程序组合成可引导磁盘映像。安装cargo install bootimage运行bootimage与编译引导程序还需要 rustup 组件llvm-tools-previewrustup component add llvm-tools-preview安装完成后创建引导映像只需一条命令 cargo bootimagebootimage会用cargo build重新编译内核自动增量编译改动随后编译引导程序首次较慢但像所有依赖一样会被缓存后续构建快很多最后把两者组合为可引导磁盘映像。运行后在target/x86_64-blog_os/debug目录中会出现映像文件bootimage-blog_os.bin。可以在虚拟机中启动它也可以刻录到 U 盘在真机启动。注意.bin不是光驱映像格式刻录到光盘不会起作用。bootimage 幕后做了什么bootimage工具实际执行三个步骤把内核编译为ELFExecutable and Linkable Format文件把引导程序依赖编译为独立可执行文件把内核 ELF 文件按字节拼接append到引导程序末端。机器启动时引导程序读取并解析拼接在后的 ELF 文件然后把程序片段映射到分页表中的虚拟地址清零BSS 段创建栈读取入口点地址即_start函数的位置并跳转过去。在 QEMU 中启动内核在 QEMU 虚拟机中启动内核 qemu-system-x86_64 -drive formatraw,filetarget/x86_64-blog_os/debug/bootimage-blog_os.bin命令会弹出一个独立窗口屏幕上显示 Hello World!祝贺你已经拥有了一个能引导、能输出的最小内核在真机上运行内核也可以把映像写入 U 盘在真机上引导 dd iftarget/x86_64-blog_os/debug/bootimage-blog_os.bin of/dev/sdX sync其中sdX是 U 盘的设备名device name。选择设备名时务必极其小心目标设备上的所有数据都会被擦除写入后在真机上通过启动菜单或调整 BIOS 启动顺序从 U 盘引导。需要提醒的是bootloadercrate 目前不支持 UEFI所以无法在 UEFI 机器上启动。用cargo run一键启动为了让 QEMU 运行更省事可以在 cargo 配置中设置runner# in .cargo/config.toml [target.cfg(target_os none)] runner bootimage runnertarget.cfg(target_os none)匹配所有目标配置中os字段为none的编译目标——包含我们的x86_64-blog_os.jsonrunner键规定cargo run成功后执行的命令可执行文件路径会作为第一个参数传入bootimage runner命令由bootimage包提供专为runner场景设计把给定的可执行文件与项目的引导程序依赖链接然后在 QEMU 中启动。此后一条cargo run即可完成编译内核 QEMU 启动。小结与本系列的下一步至此我们从启动原理出发完成了理解 BIOS 引导流程与引导程序职责、编写面向裸机的x86_64-blog_os.json目标配置清单、用build-std为自定义目标重编译core与compiler_builtins、启用compiler-builtins-mem提供内存函数、通过bootimage生成可引导映像并最终让内核在 QEMU 与真机上打印出 Hello World!。每一步对应的仓库证据都可以在源码中核对目标配置的核心字段与panic-strategy、disable-redzone、features的含义见本教程正文红区与 SIMD 的深入解释见配套短文禁用红区与禁用 SIMD前置的独立二进制构建步骤见独立式 Rust 可执行程序。下一篇将细致探索 VGA 字符缓冲区把它包装为安全的接口并基于它实现println!宏——那是你第一个真正内核驱动的雏形。赞分享文档教程技术博客操作系统【免费下载链接】blog_osWriting an OS in Rust项目地址https://gitcode.com/GitHub_Trending/bl/blog_os点击查看免费下载相关推荐用 Rust 编写最小 x86_64 内核从裸机目标到 QEMU 里的 Hello Worldblog_os 实战指南用 Rust 编写最小 x86_64 内核从裸机目标到 QEMU 里的 Hello Worldblog_os 实战指南 本指南以 blog_os 项目《A文档教程技术博客操作系统用 Rust 编写最小 x86_64 内核从 freestanding 二进制到可引导的 Hello World 磁盘映像用 Rust 编写最小 x86_64 内核从 freestanding 二进制到可引导的 Hello World 磁盘映像 本篇技术指南承接《A Free文档教程技术博客操作系统用 Rust 编写最小 x86_64 内核blog_os 项目从 freestanding 二进制到 Hello World!用 Rust 编写最小 x86_64 内核blog_os 项目从 freestanding 二进制到 Hello World! 本篇指南完整讲解 blog文档教程技术博客操作系统上一篇graph-autofusion SuperKernel 自动调优控制器硬性适配契约controller-legacy-contract全面解析下一篇OneUptime Terraform Provider 完整实战指南认证、依赖编排、数据源与状态管理创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考