ArceOS 与 StarryOS 异步网卡实现对比¶
标签：async, nic, arceos, starryos
ArceOS 项目中的以太网驱动与异步封装，和 StarryOS 项目中的异步网卡数据面，属于两条不同的实现路线：前者以目标硬件开发板驱动先行，异步封装后补；后者先以模拟器完成软件分层，真机方案延后。两者不能直接互用，但可互相借鉴。
ArceOS¶
时间跨度为 2025 年 5 月至 10 月，向主仓库提交 84 次，向驱动实现子模块提交 30 余次，目标是让网卡在目标开发板上收发数据。
- 驱动层：完成以太网介质访问控制控制器所需的基本寄存器配置、收发描述符环形队列、物理层收发器配置和中断处理，均在真机运行验证。
- 异步层：为连接套接字提供接收、发送、接受连接、建立连接四种异步操作，并改造异步运行时；设备中断处理函数持全局锁调用轮询整条收发链，唤醒回调由轮询过程触发。
- 遗留缺陷：接受连接操作在资源暂不可用时没有登记唤醒回调，依赖外部周期轮询，否则该操作永久等待；设备就绪状态不透出异步上下文，靠中断处理函数主动触发整链轮询；全局的设备、接口与套接字锁在对称多处理与多队列场景下不适用。
StarryOS（我的实现）¶
面向模拟器平台，第 4 至第 7 阶段已完成并按验收证据归档。
- 分层数据面：硬中断处理函数只做原因读取、应答、屏蔽与唤醒，数据搬运交给按队列划分的处理任务；协议栈推进由独立的协议栈执行任务承担，独占地持有协议栈接口与套接字集合。收发描述符由队列归属者推进，数据包通过所有权凭证转移。
- 正确性机制：使用原子唤醒原语配合"登记后复查"，避免丢失唤醒；每轮处理量设上限防忙等；描述符状态机配合复位代次隔离迟到的完成事件；压力过高时在队列层背压。
- 运行时：复用既有的任务调度器，不引入自研异步执行器；等待原语取自同步库。
- 真机：尚未开展，目标开发板未确定，待目标硬件事实检查通过后决定。
差异对照¶
| 维度 | ArceOS | StarryOS |
|---|---|---|
| 起点 | 真机硬件先行 | 模拟器软件分层先行 |
| 中断处理职责 | 处理函数持锁轮询整链 | 处理函数只做唤醒，搬运在队列任务 |
| 协议栈推进 | 中断回调触发 | 协议栈执行任务在任务上下文推进 |
| 压力与预算 | 未建立 | 每轮处理量上限、显式背压 |
| 数据所有权 | 无描述符归属概念 | 描述符状态机、所有权凭证、复位代次 |
| 丢失唤醒 | 存在该缺陷 | 原子原语配合登记后复查 |
| 异步运行时 | 自研执行器 | 复用既有调度器 |
| 验证顺序 | 直接真机 | 模拟器分层证据，真机待事实检查 |
差异原因¶
起点不同使整条实现路径不同。ArceOS 需先让网卡在真机完成收发，驱动落地与运行优先，异步只是为套接字提供一层可等待的封装，正确性机制没有单独建立。StarryOS 在模拟器上先把数据所有权、竞争与恢复处理完毕，真机由事实检查决定，因此"中断处理只唤醒、队列任务搬数据、协议栈执行任务跑协议栈"的分层，正是针对前一条实现中处理函数做重活、操作永久等待、锁粒度过大等问题重构而来。
可借鉴之处¶
- ArceOS 中的缓存一致性处理、处理器地址与总线地址分离、真机时钟复位与中断事实具有复用价值；真机阶段按控制器类型决定采用其代码还是仅采用经验。
- 模拟器只能验证软件层的数据所有权、中断到队列任务再到协议栈的控制流与多数软件竞争条件，无法验证真机的缓存、直接内存访问、中断时序或吞吐，真机结论需另行取证。
来源¶
- ArceOS 部分：ArceOS 仓库
.claude/analysis/mingyang-overview.md、mingyang-async-network.md（2026-06-26 生成）。 - StarryOS 部分：StarryOS 仓库
.claude/analysis/async-network-project-overview.md、.claude/docs/tasks.md（第 4 至第 7 阶段归档）。
以上内容依据既有分析整理，尚未核对两边仓库当前提交状态；提交号、行号与最新状态以两仓库实际代码为准。