huanhuanou-CSDN博客

原创 Gdev 至 Rust 移植工程（十二）

C 版本中普遍存在的无边界检查、错误码类型混淆、空指针解引用等问题，在 Rust 版中通过Option<T>RAII DropMutex串行化、newtype等机制被彻底根除。Rust 的类型系统与所有权模型不是在写“更好的 C”，而是在编译器层面强制实施内存安全与并发安全，将原本需要人工审查的约束变成了机器可验证的规则。从 C 到 Rust，SDAA 运行时在安全性上有较大提升——8 类内存与并发漏洞，而在性能上不仅没有倒退，反而因精简了历史冗余而略有提升。

2026-06-05 17:59:37 391

原创 Gdev 至 Rust 移植工程（十一）

前面四个 Layer 翻译完成，14 个集成测试全部通过，甚至在 QEMU 上完成了安全性和性能的 A/B 对比实验。一切看起来都非常完美。直到有一天，我们做了一个底层原生 API 的基准测试——不经过 SDAA Runtime 那一层封装，直接调用最底层的 gmalloc/gmemcpy_to_device/gsync 来测 DMA 带宽。出现了一个非常荒谬的结果。Rust 版的 DMA 耗时只有 0.02 毫秒。这不是 DMA，这是量子纠缠。

2026-05-29 18:08:07 450

原创 Gdev 至 Rust 移植工程（十）

3 类已验证 Rust 优势（#1、#4、#6），2 类间接可验证（#2、#7），3 类为编译期/防御性优势（#3、#5、#8）。Rust 版本在所有可测试漏洞上均优于或等于原版 C。我们对照原版 C 代码里真实存在的 8 类问题，逐个看 Rust 怎么防，以及哪些已经用 A/B 测试验证过了。热点在硬件路径，不在语言。对比 C vs Rust 的均值±标准差。目前c版本的so库有较多打印，正在控制变量，待后续进一步详细对比。C 和 Rust 走的是完全相同的硬件路径——同一个。性能理论上分析几乎没差距。

2026-05-26 17:46:15 423 4

原创 Gdev 至 Rust 移植工程（九）

前四层翻译完成后，我们在开发机上跑通了全部 196 个单元测试。但在 QEMU 验证机（CentOS 7, glibc 2.17, 4 块 aicard 设备）上，最初只是用一个在用户态模拟设备内存，内核启动也在 CPU 上软件完成——数据从未真正进入 AI 加速卡。为了验证翻译的正确性，必须让 Rust 运行时像原版 C 库一样，通过 ring buffer 协议将操作码和参数推入，由内核模块aicard.ko翻译成 PCIe MMIO 寄存器写入，驱动。

2026-05-22 17:48:18 391

原创 Gdev 至 Rust 移植工程（八）

四层翻译完成：L1 AIDEV ioctl 封装、L2 gdev 核心抽象、L3 SDAA Driver API、L4 Ocelot Runtime（惯用 Rust 重设计）。31 个 .rs 文件，~10,300 行，196 个单元测试 0 失败。cargo build --release 产出 libgdev_layer2.so + libgdev_layer4.so，对标原版 C 写的 libgdev.so + libusdaa.so。

2026-05-20 17:46:05 384

原创 Gdev 至 Rust 移植工程（七）

前四阶段的翻译工作已全部完成（31 文件，10,300 行 Rust，196 个纯软件测试通过），并在开发机上成功编译出。

2026-05-19 18:09:34 381

原创 Gdev 至 Rust 移植工程（六）

前四个阶段的翻译工作已全部完成，196 个测试在无硬件环境下全部通过。接下来的目标是将编译出的动态库部署到 QEMU 模拟的 CentOS 7 虚拟机中，用真实的 C 测试程序验证能否正常调用。测试环境由跳板机上的 CentOS 7 QEMU 模拟器提供，其中已包含原版的libgdev.so和，以及配套的 C 测试样例（如launch.c。

2026-05-15 17:50:42 358

原创 Gdev 至 Rust 移植工程（五）

22,500 行 C++从 22,500 行 C++ 到 ~3,400 行 Rust，缩减 85%。SdaaDriver.cpp (658 行) — 完全删除。这个文件是 C++→C 的 pass-through 层，每个函数都是一行 return ::sdFunction(…)。Rust 中 Layer 4 直接调 Layer 3 FFI，不需要这个中间人。Hydrazine 工具库 (~3,000 行) — 被 Rust 标准库和社区 crate 替代。

2026-05-14 17:35:38 582

原创 Gdev 至 Rust 移植工程（四）

阶段C 行数Rust 行数测试核心翻译挑战Stage 3.11746 字段结构体对齐 + 40+ 错误码穷举 + 6 种句柄的 repr(transparent)Stage 3.221SDcontext newtype 指针穿透 (19 errors) + Layer 2 Result/Option 语义映射 (24 errors) + SDctx_st 字段补全 (11 errors)Stage 3.325。

2026-05-13 17:15:36 410

原创 Gdev 至 Rust 移植工程（三）

昨天一阶段的bug修复感觉有问题，代码如下从这里可以看到chmap_base本来是mmap后返回的指针，后边还跟上了检测，如果mmap失败则直接返回错误，但是随后突然冒出来一句赋值0，后边和苏工交流之后这个是代码历史遗留问题，这里使用的映射内核层已经做了，就不需要再去做了，直接使用0基地址即可，最后在对应的rust代码里也回退了相关修改，保持为0。接下来是第二阶段的目前进度以及详细过程。

2026-05-12 17:41:32 948

原创 Gdev 至 Rust 移植工程（二）

目标：产出 types.rs，包含所有这些的类型安全等价物，外加一份 lib.rs 做模块声明。

2026-05-11 17:57:26 499

原创 Gdev 至 Rust 移植工程（一）

按核心类型、公共 API、调度器框架、完整集成的顺序，将 gdev_device.c、gdev_api.c 及四种调度策略翻译为 trait Scheduler 的多态实现，并贯通 glaunch、gsync 等核心操作。

2026-05-09 18:00:35 629

原创面向 C→Rust 重构的专用智能体构建与评估（五）

在上一阶段的深度排障中，我们成功锁定了阻碍函数体通过率跨过 73% 天花板的根本原因——typedef条目产生的空结构体壳在符号层面引发了Ptr<T>泛型参数的类型坍缩。然而，由于此前调试过程中反复修改max_trial参数并遗留了大量交叉引用的缓存文件，导致流水线执行频繁触发超时与依赖混乱。为彻底排除环境干扰，我们决定从零构建一个干净的 EvoC2Rust 工作目录，并在此之前进一步强化 OpenCode 编码智能体的基础能力，以更精确地辅助对翻译失败的诊断与修复。

2026-04-29 17:48:57 454

原创面向 C→Rust 重构的专用智能体构建与评估（四）

在上一阶段的实验中，EvoC2Rust 的三级修复流水线将项目的函数体编译通过率从 54.50% 提升至 73.00%，但仍有 54 个函数体未能通过翻译验证。这挡在通往全自动 Rust 化路径前的 27%，其核心障碍并非翻译能力的缺失，而是更深层的。本章我们将使用 OpenCode 编码智能体对失败日志展开系统性诊断，定位根因并设计针对性修复方案。

2026-04-28 17:31:50 393

原创面向 C→Rust 重构的专用智能体构建与评估（三）

在上一阶段的实验中，我们成功驱动 EvoC2Rust 完成了元数据提取与 LLM 翻译两大流水线，将示例项目中的 29 个宏、95 个类型定义、200 个函数签名及 200 个函数体从 C 映射为 Rust 中间表示，并转入了编译修复流程。本文将深入剖析修复阶段的三级串行机制、验证环节的缓存一致性问题，以及最终 Rust 项目的生成与编译验证结果。

2026-04-27 17:26:45 387

原创面向 C→Rust 重构的专用智能体构建与评估（二）

在前一阶段的实验中，我们基于 OpenFang 的 Hands 机制成功构建了面向 Gdev/SDAA 加速卡驱动重构的专用智能体。然而，实际压力测试揭示了 OpenFang 作为通用 Agent 操作系统在面对生产级代码重构任务时的结构性瓶颈——其 Shell 沙箱对管道符、重定向等原语的严格过滤，以及默认的 50 次自主迭代上限，使得大规模源码分析与构建流程的执行极为受限。官方文档亦表明，OpenFang 的设计初衷更偏向多场景生活化 Agent 的编排与安全治理，而非高性能的编码密集型任务。

2026-04-24 17:58:04 456

huanhuanou的博客