前言
2022年7月，一个由高校学生和开源爱好者组成的社区，决定做一件"疯狂"的事：用 Rust 语言从零开始写一个操作系统内核，并且让它能够运行 Linux 二进制程序。
四年过去了，这个项目已经积累了 20 万行代码、72 位贡献者、1100+ 个 Pull Request，GitHub Star 稳居国内 Rust OS 领域前三。它的名字叫 DragonOS——一个面向云计算 Serverless 场景的、云原生设计的、完全自主可控的操作系统内核。
如果你对操作系统内核开发感兴趣，对 Rust 在系统编程领域的应用有好奇，或者想知道国产操作系统还有哪些技术路线值得探索，DragonOS 是一个非常值得深入了解的项目。本文将从架构设计、核心子系统、云原生特性、eBPF 虚拟化技术、Linux 兼容性等多个维度，对 DragonOS 进行一次完整的技术拆解。
一、背景：为什么还需要一个新的操作系统内核？
1.1 现有方案的痛点
在 DragonOS 诞生之前，开源操作系统内核领域已经有了几个成熟的 Rust 方案：
rcore 是清华大学出品的 Rust OS 教学内核，代码质量高，但定位是教学实验，生产环境应用有限。Tokio-unix 探索了 Rust 在 Unix 系统编程中的可能性，但更偏向异步运行时而非完整内核。Tifflin 是另一个实验性 Rust 内核，采用了非 POSIX 设计哲学，更像一个创新性研究项目。
而 Linux 内核本身，虽然在服务器领域无可替代，但其 3000 万行 C 代码带来的历史包袱是沉重的——每年仍有大量内存安全漏洞被披露。Android、ChromeOS 等基于 Linux 的产品不断在后端打补丁，但根本性的架构改变几乎不可能。
DragonOS 想要做的，是在吸收 Linux 生态红利（软件生态、二进制兼容性）的同时，用 Rust 语言从根本上提升内核的内存安全性。
1.2 为什么是 Serverless 场景？
操作系统内核的应用场景有很多：桌面、移动终端、嵌入式、服务器……DragonOS 选择 Serverless（无服务器计算）作为切入点，这是一个非常务实的定位。
Serverless 场景有几个关键特征：
- 轻量化：不需要完整的桌面环境和复杂的用户态生态
- 高并发：大量短生命周期函数实例，对调度器和容器化有高要求
- 网络密集：函数编排、API 网关，对网络子系统性能敏感
- 安全隔离：多租户环境下容器和进程隔离是核心需求
这些特征恰好对应了 DragonOS 的核心能力：Rust 带来的轻量高性能、内置 eBPF 和容器支持、KVM 虚拟化、以及对云原生基础设施的优化。
1.3 DragonOS 的核心设计目标
根据官方文档，DragonOS 制定了清晰的技术目标：
- 完全自主内核：从零研发，不基于任何现有内核，确保供应链安全
- Rust 语言驱动：用 Rust 的所有权系统和类型安全，从根本上减少内存安全漏洞
- Linux 二进制兼容：通过 Linux 系统调用兼容层，使现有 Linux 程序无需重新编译即可运行
- 云原生优先：eBPF 虚拟机、KVM 虚拟化、容器命名空间等特性，为容器化 Serverless 场景优化
- 多架构支持：x86_64、RISC-V64、LoongArch64 同步开发
二、架构设计：从分层结构看 DragonOS 的工程哲学
2.1 整体架构概览
DragonOS 的代码仓库采用清晰的模块化分层结构：
DragonOS/
├── kernel/ # 内核空间代码
│ ├── arch/ # 架构相关代码（x86_64, RISC-V, LoongArch）
│ ├── drivers/ # 设备驱动
│ ├── fs/ # 文件系统（ext4, devfs, procfs, sysfs）
│ ├── net/ # 网络子系统
│ ├── mm/ # 内存管理
│ ├── process/ # 进程与调度管理
│ └── syscall/ # 系统调用接口
├── user/ # 用户态程序与库
├── tools/ # 构建工具与辅助脚本
└── docs/ # 架构文档
这种分层设计的核心原则是：在内核空间最大程度复用 Rust 的类型系统和借用检查器，在用户态则通过 POSIX 兼容层支持现有 Linux 生态。
2.2 构建系统：Makefile + Rust 工具链
DragonOS 的构建系统基于 GNU Make，核心 Makefile 片段如下：
SUBDIRS = kernel user
# 架构设置
export ARCH=__x86_64__
export ROOT_PATH=$(shell pwd)
export DEBUG=DEBUG
# 编译选项：关闭栈保护、启用大地址模型、禁用内联优化
export GLOBAL_CFLAGS := -mcmodel=large -fno-builtin -m64 \
-fno-stack-protector -D $(ARCH) -D DEBUG
# x86_64 平台检测
ifeq ($(OS),Linux)
NPROCS:=$(shell grep -c ^processor /proc/cpuinfo)
endif
这个构建配置透露出几个重要信息：
- 关闭栈保护 (
-fno-stack-protector)：因为 DragonOS 自己实现了栈溢出检测机制 - 大地址模型 (
-mcmodel=large)：允许内核代码访问全部 64 位地址空间 - 禁用内联 (
-fno-builtin)：避免编译器优化干扰内核行为，便于调试
构建系统支持多平台检测，在 Linux 和 macOS 上自动适配编译器参数，并可通过 EMULATOR 变量切换 QEMU 模拟环境。
三、进程与内存管理：Serverless 场景的性能基石
3.1 进程与线程模型
DragonOS 在 0.2.0 版本中引入了完整的进程组和线程组机制，以及命名空间支持。这是实现容器化的基础设施。
命名空间支持是容器技术的核心。DragonOS 目前已实现：
- PID 命名空间：隔离进程 ID 空间，每个容器看到的进程 ID 从 1 开始
- Mount 命名空间：隔离文件系统挂载点，
unshare --mount可创建独立的挂载视图 - UTS 命名空间：隔离主机名和域名，
hostname命令在容器内不影响宿主机 - User 命名空间：用户 ID 和组 ID 的映射隔离，增强安全边界
- IPC 命名空间：隔离 System V IPC 和 POSIX 消息队列
0.3.0 版本中，这些命名空间进一步向 Linux 主线行为对齐，修复了包括 vfork 行为、CLONE_PARENT_SETTID、signal frame 等多项历史遗留问题，显著提升了 Go 语言等多线程程序的兼容性。
线程组退出机制的实现值得关注。在 Linux 中，一个进程内的所有线程共享进程 ID，而线程有自己的线程 ID（TID）。DragonOS 实现了线程组退出机制——当主线程退出时，整个线程组的退出状态由主线程决定：
// DragonOS 进程创建（伪代码）
pub fn do_fork(pt: &ProcessManager, args: &ForkArgs) -> Result<PidHandle> {
let current = pt.current_process();
// 复制进程控制块
let child_pcb = current.duplicate()?;
// 设置父子关系：CLONE_PARENT_SETTID 语义
if args.flags.contains(CloneFlags::CLONE_PARENT_SETTID) {
// 将子进程 PID 写回父进程指定的内存位置
unsafe {
*(args.parent_tid as *mut Pid_t) = child_pcb.pid();
}
}
// 复制线程组信息
if args.flags.contains(CloneFlags::CLONE_THREAD) {
child_pcb.set_tgid(current.tgid());
} else {
child_pcb.set_tgid(child_pcb.pid()); // 独立线程组
}
Ok(child_pcb.pid_handle())
}
3.2 内存管理与 Futex 同步
Futex（Fast Userspace Mutex） 是 Linux 高性能同步的基础设施，DragonOS 0.3.0 对 Futex 子系统进行了全面重构。
Futex 的核心价值在于：无竞争时完全在用户态完成加锁和解锁，系统调用只在锁冲突时才进入内核。这使得高并发场景下的同步开销极低。
0.3.0 的 Futex 改进包括：
- PI Futex（Priority Inheritance Futex）：解决优先级反转问题，确保高优先级进程不会被低优先级进程持有的锁阻塞太久
- Robust List 竞态修复：修复了进程异常退出时 Futex 状态清理的竞态条件
- Wake Operation 兼容性：与 Linux 的
FUTEX_WAKE_OP操作完全兼容
// Futex wake 操作（DragonOS 实现）
pub fn sys_futex(
uaddr: UserPtr<u32>,
op: FutexOp,
val: u32,
timeout: UserPtr<TimeSpec>,
uaddr2: UserPtr<u32>,
val3: u32,
) -> Result<isize> {
let op_type = op & FUTEX_CMD_MASK;
match op_type {
FUTEX_WAIT => {
// 无竞争时用户态自旋，有竞争才进入内核
let current_val = uaddr.read_volatile();
if current_val != val {
return Err(EAGAIN); // 值已变化，立即返回
}
// 进入内核等待队列
self.block_futex(uaddr, timeout)?
}
FUTEX_WAKE => {
// 唤醒 val 个等待者
self.wake_futex_waiters(uaddr, val as usize)?
}
FUTEX_WAKE_OP => {
// 复合操作：wake + 原子修改
let wake_val = (val3 >> 12) & 0xfff;
self.wake_futex_waiters(uaddr, wake_val as usize)?
}
_ => return Err(EINVAL),
}
Ok(0)
}
内存分配器方面，DragonOS 实现了 Slab/Buddy 分层分配机制，并在 0.3.0 中修复了伙伴分配器的高负载死锁问题。VM_DONTCOPY、mincore、madvise 等 Linux 内存管理接口也逐步完善。
四、文件系统：从 ext4 到 OverlayFS 的容器化支撑
4.1 ext4 文件系统实现
ext4 是 Linux 生态中最成熟的日志文件系统，DragonOS 0.2.0 引入了对 ext4 的读写支持，这是实现 Linux 二进制兼容的关键一步。
DragonOS 的 ext4 实现支持：
- 从 VirtIO 块设备和 SATA 磁盘挂载 ext4 分区
- 完整的目录操作、文件创建/读写/删除
- extent 存储方式（相比 ext2/3 的块映射，大文件性能提升显著）
- 日志功能（可选，权衡性能与数据安全）
4.2 OverlayFS：容器镜像的分层之道
OverlayFS 是容器镜像技术的核心——它允许将多个只读层叠加到一个统一的可写视图上。DragonOS 对 OverlayFS 的支持，使得容器镜像的分层结构和写时复制成为可能。
# OverlayFS 在 DragonOS 中的挂载示意
mount -t overlay overlay \
-o lowerdir=/var/container/basefs,/var/container/app_layer,\
upperdir=/var/container/upper,\
workdir=/var/container/work \
/var/container/merged
在 DragonOS 中：
lowerdir：容器的只读基础层（镜像层）upperdir：容器的可写层（所有写操作进入此层）workdir：OverlayFS 工作目录（元数据操作的中转）
这种设计使得多个容器可以共享同一基础镜像，而每个容器各自的修改被隔离到 upperdir，既节省存储空间，又实现了完美的隔离性。
4.3 sysfs 与 procfs
DragonOS 还实现了 sysfs 和 procfs 虚拟文件系统。这两个文件系统是 Linux 用户态工具（如 ps、top、lsblk）获取内核状态的主要窗口：
# DragonOS 中的 procfs 文件示例
/proc/cpuinfo # CPU 信息
/proc/meminfo # 内存使用情况
/proc/[pid]/ # 每个进程的详细信息
# sysfs 暴露内核对象
/sys/block/ # 块设备
/sys/class/net/ # 网络接口
/sys/devices/ # 设备树
0.3.0 版本还实现了 get_mempolicy、rlimit 框架和 RLIMIT_FSIZE，使得资源观测和限制能力更加细粒度。
五、eBPF：在内核中运行沙箱程序的革命性特性
5.1 为什么 eBPF 对云原生操作系统如此重要？
eBPF（extended Berkeley Packet Filter）是 Linux 内核中的一项革命性技术——它允许你在内核中运行沙箱程序，无需修改内核源代码或加载内核模块。eBPF 程序由内核验证器（Verifier）确保安全后，在内核中 JIT 编译执行，性能接近原生代码。
DragonOS 是国内率先支持 eBPF 的自研 OS，并且可以使用 Linux 原生 bpf 工具链为 DragonOS 编写 eBPF 程序。这不是一件简单的事——它意味着 DragonOS 的 eBPF 虚拟机 ABI 与 Linux 基本兼容。
5.2 DragonOS 的 eBPF 架构
DragonOS 的 eBPF 实现包含以下核心组件：
BPF 虚拟机：负责执行 BPF 字节码。DragonOS 的 JIT 编译器将 BPF 字节码直接编译为 x86_64 机器码：
// eBPF JIT 编译器核心逻辑（伪代码）
pub fn jit_compile(bpf_program: &[BpfInsn]) -> Vec<u8> {
let mut machine_code = Vec::new();
for insn in bpf_program {
match (insn.opcode, insn.dst_reg, insn.src_reg) {
// BPF_ALU64_ADD: R0 = R0 + R1
(0x0f, 0, 1) => {
machine_code.push(0x48); // REX.W prefix
machine_code.push(0x01); // add r/m64, r64
machine_code.push(0xc1); // ModRM: mod=11, reg=0(R0), R/M=1(R1)
}
// BPF_JMP_JEQ: if R0 == imm then pc += off
(0x15, 0, _) => {
let off = insn.off as i32;
machine_code.push(0x48); // REX.W
machine_code.push(0x81); // cmp r/m64, imm32
machine_code.push(0xf8); // ModRM: R0
machine_code.extend_from_slice(&(insn.imm as u32).to_le_bytes());
// jz near offset
machine_code.push(0x0f);
machine_code.push(0x84);
machine_code.extend_from_slice(&(off as u32).to_le_bytes());
}
_ => unimplemented!("Unsupported BPF instruction: {:?}", insn),
}
}
machine_code
}
kprobe 挂钩：kprobe 允许在任意内核函数的入口或返回点插入探针：
# 在 DragonOS 中附加 kprobe（伪命令）
bpftrace -e 'kprobe:schedule { @ = count(); }'
5.3 用 Aya 框架在 Rust 中编写 eBPF 程序
Aya 是 Rust 生态中最成熟的 eBPF 开发框架，DragonOS 官方推荐使用 Aya 编写 eBPF 程序：
// user/src/main.rs - 用户态加载程序
use aya::programs::{KProbe, KRetProbe, TracePoint};
use aya::Bpf;
use aya_log::BpfLogger;
use tokio::signal;
#[tokio::main]
async fn main() {
// 加载 eBPF 程序
let mut bpf = Bpf::load("dragonos_ebpf.bpf.o")?;
let _ = BpfLogger::try_load(&mut bpf);
// 附加 kprobe 到 schedule 函数
let schedule_program: &mut KProbe = bpf.program_mut("schedule_enter")?;
schedule_program.load()?;
schedule_program.attach("schedule", 0)?;
info!("eBPF 程序已加载，等待信号退出...");
signal::ctrl_c().await?;
}
// ebpf/src/main.rs - eBPF 内核程序
use aya_ebpf::macros::{kprobe, kretprobe, tracepoint};
use aya_ebpf::programs::ProbePayload;
#[kprobe]
pub fn schedule_enter(_payload: ProbePayload) {
unsafe {
let ts = TIMESTAMPS.get_or_init(|| [0u64; 1024]);
let idx = (CPU_ID.load() % 1024) as usize;
ts[idx] = bpf_ktime_get_ns();
}
}
#[tracepoint]
pub fn sched_switch(payload: TracePayload) -> u32 {
let prev_pid = payload.as_ref().prev_pid() as i32;
let next_pid = payload.as_ref().next_pid() as i32;
0
}
5.4 eBPF 在 DragonOS 中的实际应用场景
- 网络流量监控：在网卡驱动层附加 XDP（eXpress Data Path）程序，实现零拷贝包过滤
- 性能剖析：kprobe 挂钩关键内核函数，统计调用频率和延迟分布
- 安全审计：track 系统调用参数，检测异常行为模式
- 容器网络：结合 cgroup 限制，实现细粒度的网络带宽控制
六、虚拟化：KVM 与 VirtIO 的双剑合璧
6.1 KVM 虚拟化架构
KVM（Kernel-based Virtual Machine）是 Linux 的原生虚拟化解决方案，DragonOS 0.2.0 对 KVM 子系统进行了重构，支持 Intel CPU 的 CPU 和内存虚拟化。
KVM 的核心原理是硬件辅助虚拟化：利用 Intel VT-x（或 AMD-V）指令集，在 CPU 层面实现虚拟机和宿主机之间的切换（VMX Root Mode ↔ VMX Non-Root Mode）。
DragonOS 的 KVM 实现支持：
- VMX 非根模式：虚拟机在受限环境中运行，触发特定指令或事件时 VM-Exit
- VMCS（Virtual Machine Control Structure）：管理 VM-Exit 条件、guest 状态和 host 状态切换
- EPT（Extended Page Table）：二级页表实现虚拟机物理地址到宿主机物理地址的转换
6.2 VirtIO：高效虚拟化 I/O
VirtIO 是虚拟化 I/O 的标准协议。与传统的模拟设备（如 QEMU 模拟的 IDE 硬盘）相比，VirtIO 通过共享内存和 virtqueue 机制，实现了接近物理设备的性能：
// VirtIO 块设备驱动的核心结构
pub struct VirtIoBlkDevice {
base_addr: PhysAddr,
common_cfg: &'static VirtIoPciCommonConfig,
device_cfg: &'static VirtIoBlkConfig,
// virtqueue：用于 DMA 传输的环形缓冲区
request_queue: VirtQueue,
}
impl VirtIoBlkDevice {
/// 发送一个块设备读写请求
pub fn read_block(&mut self, sector: u64, buf: &mut [u8]) -> Result<()> {
// 1. 从对象池获取请求（避免分配）
let mut req = VirtIoBlkReq::from_pool();
req.header.type_ = VirtIoBlkType::IN;
req.header.sector = sector;
req.set_data(buf);
// 2. 将请求添加到 virtqueue
self.request_queue.add(&[], &[req.as_slice()])?;
// 3. 通知前端
self.notify_device();
// 4. 等待完成
self.request_queue.wait_for_completion(&mut req)?;
Ok(())
}
}
DragonOS 已支持的 VirtIO 设备：
- VirtIO Block：虚拟磁盘
- VirtIO Console：虚拟串口
- VirtIO Network：虚拟网卡（0.3.0 重构后支持）
- VirtIO Balloon：动态内存气球
6.3 中断多路复用
0.2.0 版本还引入了中断多路复用机制。在传统虚拟化环境中，每个虚拟设备都可能产生中断，在高 I/O 负载下，中断风暴会导致 CPU 资源大量消耗在中断处理上。DragonOS 通过中断多路复用，将多个设备的中断合并处理，显著降低了中断处理开销。
七、网络子系统：重构之后的新架构
7.1 从 0.2.0 到 0.3.0 的网络架构演进
网络子系统是 DragonOS 0.3.0 中变化最大的部分之一。0.2.0 版本的网络功能较为基础，而 0.3.0 对网络子系统进行了全面重构，目标是实现与 Linux 更接近的行为和更好的可扩展性。
新网络架构设计：
// DragonOS 网络子系统核心架构（伪代码）
pub mod network {
// 分层网络栈
pub mod transport { /* TCP/UDP 实现 */ }
pub mod internet { /* IPv4/IPv6 实现 */ }
pub mod link { /* Ethernet, ARP */ }
pub mod socket { /* BSD Socket 接口 */ }
// 设备驱动层
pub mod drivers {
pub mod virtio_net; // VirtIO 网卡
pub mod loopback; // 回环设备
pub mod bridge; // 桥接网络
}
}
7.2 桥接网络：容器互联的关键
桥接（Bridge）网络是容器网络的基础模型。在 DragonOS 0.3.0 中，新增了桥接网络支持：
# 在 DragonOS 中创建桥接网络
ip link add br0 type bridge
ip link set eth0 master br0
ip link set veth_container1 master br0
ip link set br0 up
ip addr add 10.0.0.1/24 dev br0
# 容器内自动获得 IP
ip addr add 10.0.0.2/24 dev eth0
ip route add default via 10.0.0.1
有了桥接网络，同一主机上的多个容器可以通过 Docker 风格的网络模型互联，也可以通过 NAT 访问外部网络。
7.3 Dropbear SSH 服务器
0.3.0 还引入了 Dropbear SSH 服务器。Dropbear 是一个轻量级的 SSH 实现，非常适合资源受限的 Serverless 环境。通过 SSH 访问 DragonOS 实例，可以远程管理容器化的工作负载。
八、Linux 二进制兼容性：站在 Linux 巨人肩膀上的务实路线
8.1 为什么二进制兼容比源码兼容更重要？
传统的操作系统兼容性方案有两种思路：
- 源码兼容（如 Wine）：通过重新编译源码适配新系统，工程量大
- 二进制兼容（如 Linux兼容层）：直接运行已有 Linux 二进制程序，用户零迁移成本
DragonOS 选择的是第二条路——Linux 二进制兼容。这意味着你可以在 DragonOS 上直接运行 nginx、Redis（如果依赖兼容）、甚至整个 Ubuntu 24.04 的原生应用程序，而无需重新编译。
8.2 系统调用兼容层
Linux 二进制兼容的核心是系统调用翻译层：
// DragonOS Linux 系统调用适配层
pub fn translate_syscall(nr: u64, args: &[u64]) -> Result<SyscallResult> {
match nr {
SYS_write => {
let fd = args[0] as i32;
let buf_ptr = UserPtr::from_raw(args[1]);
let len = args[2] as usize;
if !buf_ptr.is_user_accessible(len) {
return Err(EFAULT);
}
let written = do_write(fd, buf_ptr, len)?;
Ok(SyscallResult::Success(written as u64))
}
SYS_mmap => {
let addr = args[0] as *mut c_void;
let len = args[1] as usize;
let prot = MemoryProtection::from_bits(args[2] as u32);
let flags = MMapFlags::from_bits(args[3] as u32);
let fd = args[4] as i32;
let offset = args[5] as u64;
translate_mmap(addr, len, prot, flags, fd, offset)
}
_ => {
warn!("Unimplemented Linux syscall: nr={}", nr);
Err(ENOSYS)
}
}
}
DragonOS 在 0.2.0 到 0.3.0 的演进过程中，新增了数十个 Linux 系统调用支持。
8.3 自动化兼容性测试：gVisor 测试套件
DragonOS 引入了 Google gVisor 的 Linux 系统调用自动化测试套件。该套件包含数百个测试用例，覆盖了 Linux 系统调用的各个维度。
每当有代码提交或 Pull Request 合并时，CI 系统会自动运行这些测试用例，并通过 ci-dashboard.dragonos.org 实时展示结果：
- 已通过：系统调用行为与 Linux 一致
- 待修复：行为存在差异，需开发团队修复
- 已知差异：DragonOS 主动选择的不兼容点
0.3.0 版本已通过 270+ 项 Linux 兼容性测试用例，包括 Futex、内存管理、信号处理、文件操作等多个子系统。
九、多架构支持：x86_64、RISC-V、LoongArch64
DragonOS 的野心不只是 x86_64。0.2.0 版本引入了对 RISC-V64 和 LoongArch64 的初步支持。
9.1 RISC-V：开源 ISA 的新机遇
RISC-V 是一个完全开源的指令集架构，不受专利限制，特别适合数据中心和嵌入式场景。DragonOS 对 RISC-V 的支持，意味着未来可以在 RISC-V 服务器上运行这个操作系统。
9.2 龙架构：国产 CPU 的软件生态
LoongArch（龙架构）是国产 CPU 厂商龙芯推出的指令集架构。DragonOS 对 LoongArch64 的支持，既是技术探索，也是对国产计算生态的贡献。
DragonOS 对三种架构的统一架构层设计：
// 架构无关的进程调度接口
pub trait Scheduler: Send + Sync {
fn enqueue(&self, task: Arc<Process>);
fn dequeue(&self) -> Option<Arc<Process>>;
fn tick(&self);
fn get_cpu_id(&self) -> CpuId;
}
#[cfg(target_arch = "x86_64")]
mod x86_64_scheduler;
#[cfg(target_arch = "riscv64")]
mod riscv_scheduler;
#[cfg(target_arch = "loongarch64")]
mod loongarch_scheduler;
十、构建与运行：20分钟跑起 DragonOS
10.1 环境准备
# 克隆代码仓库
git clone https://github.com/DragonOS-Community/DragonOS.git
cd DragonOS
# 安装 Rust 工具链
rustup default nightly
rustup target add x86_64-unknown-none
# 安装 QEMU
brew install qemu # macOS
# sudo apt install qemu-system-x86 # Linux
# 构建（约 10-20 分钟）
make
10.2 QEMU 启动
qemu-system-x86_64 \
-kernel bin/kernel.bin \
-hda disk.img \
-m 2G \
-nographic \
-enable-kvm \
-append "console=ttyS0"
10.3 在线 Playground
DragonOS 官方提供了 在线 Playground：
https://cnb.cool/DragonOS-Community/playground
可以直接在浏览器中体验 DragonOS 的命令行界面。
十一、社区生态：200000 行代码背后的协作模式
11.1 社区规模与组织
- 72 名开发者：来自清华、北大、上海交大、中科院等高校
- 1100+ PR：代码贡献活跃
- 20 万行代码：全栈自研
- 6 所高校：长期稳定的学术合作
- 开源之夏：连续多年参与中科院开源之夏活动
11.2 赞助体系
- 长期赞助商：中国·雅安大数据产业园
- CDN 赞助：腾讯云 EdgeOne
- 个人赞助者：50+ 位开发者社区成员
11.3 对贡献者的吸引力
DragonOS 社区已经有多位参与者在面试中斩获国内外大厂 Offer。参与一个从零构建操作系统的项目，对系统程序员来说是极好的实战训练。
十二、对比分析：DragonOS vs rCore vs Linux
| 维度 | DragonOS | rCore | Linux 内核 |
|---|---|---|---|
| 编程语言 | Rust | Rust | C |
| 二进制兼容 | Linux ABI 兼容 | 无 | 自身 |
| eBPF 支持 | ✓（国内率先） | 实验性 | 完整 |
| KVM 虚拟化 | ✓ | ✗ | ✓ |
| 目标场景 | Serverless 云原生 | 教学/研究 | 通用 |
| 代码规模 | ~20万行 | ~5万行 | ~3000万行 |
| 开发状态 | 0.3.x 活跃开发 | 稳定维护 | 成熟生产 |
| 多架构支持 | x86/RISC-V/LoongArch | RISC-V 为主 | 全架构 |
核心差异：DragonOS 的独特价值在于将 Rust 的内存安全性和 Linux 的生态系统结合起来——既不是纯教学项目（rcore），也不是需要完全抛弃既有生态的新起点（Linux）。
十三、未来路线图：2032 年目标
- 2026 年：完善容器化支持，OCI 容器运行支持上线公共服务
- 2027-2028 年：完善 Linux 兼容性，达到 80%+ 系统调用支持
- 2029-2030 年：在云平台上提供正式服务，进入生产环境测试
- 2031-2032 年：实现数据中心、骨干网络等关键基础设施的国产化替代
结语
DragonOS 是一个值得关注的技术项目，它代表了一种务实而有野心的技术路线：用 Rust 从零构建操作系统内核，同时通过 Linux 二进制兼容层嫁接成熟生态，在云原生 Serverless 场景中找到自己的定位。
从 eBPF 虚拟机的国内率先支持，到 KVM 虚拟化和容器命名空间的完整实现，从 ext4 + OverlayFS 的文件系统支持，到多架构并行的工程规划，DragonOS 展现了一个年轻但技术扎实、目标清晰的社区力量。
对于 Rust 开发者而言，DragonOS 提供了参与真实操作系统内核开发的入口。对于整个开源社区而言，DragonOS 的探索为 Rust 在系统编程领域的工业化应用提供了一个鲜活的研究样本。
下一个十年，操作系统领域的创新窗口正在打开。DragonOS 正在用自己的方式，参与书写这个故事的下半段。
参考链接：
- DragonOS 官网：https://DragonOS.org
- GitHub 仓库：https://github.com/DragonOS-Community/DragonOS
- 官方文档：https://docs.DragonOS.org
- 官方论坛：https://bbs.DragonOS.org.cn
- CI 仪表盘：https://ci-dashboard.dragonos.org
- 代码搜索引擎：http://code.dragonos.org