一次完整评审：从资源寿命到交付责任¶
“owner 已退出”为什么还不能立即释放 SDK？同样的问题会出现在持 fd 解绑、DMA 取消和升级失败中：一个对象退出了，其他持有者和异步工作可能仍然存在。评审先把这些义务写清，再扩大到系统的预算、故障和维护。
代码和测试入口见源码与版本。前置阅读：fd 生命周期、内核设备退出、SDK 契约。
SDK 的释放条件逐层完成¶
| 对象或工作 | 关闭新入口 | 收尾义务 | 可释放条件 |
|---|---|---|---|
| ingress ticket | 禁止新 submit | ACCEPT 或 REJECT | 剩余输入已处理 |
| accepted 请求 | 不再分配新槽 | 一次 TERMINAL | live=0 |
| owner | 请求协作停止 | 完成回调、业务和后端收尾 | join/完成等待成功 |
| backend | 禁止新发送 | 结束通信与执行对象 | 不再访问实例 |
| 外部 API 使用者 | 应用禁止新调用 | 已发起调用返回 | 全部调用者结束 |
| SDK 实例 | 所有入口关闭 | 上述条件全部成立 | destroy |
state=CLOSED 是业务状态；它不能替代 owner join，也不能代替应用对外部使用者的同步。等待超时保留对象，让调用者继续诊断和等待。把超时直接变成 free，会把未完成的退出变成悬空访问风险。
内核解绑提供另一组对象关系¶
教学驱动中，registry 持有一个实例引用；每个成功 open 的 session 增加引用。remove 先发布 dead，注销入口，再同步取消 delayed work、唤醒等待者并放掉 registry 引用。
probe : registry ref = 1
open : +1 session ref
remove : dead → deregister → cancel work → wake → -1 registry ref
read : 已有记录可排空，之后 EOF
release : -1 session ref；最后引用释放实例
因此设备解绑与对象释放处于不同时间点。module 的寿命、设备注册的寿命、open session 的寿命和一次异步工作的寿命也分别核对。详细实现和实验见内核生命周期。
把局部安全扩展成系统评审¶
下面的条目适合写入一次设计决定。每项标明事实、估计与未知，并引用实际测量或待执行验证。
| 评审内容 | 必须回答的问题 | 需要留下的材料 |
|---|---|---|
| 场景与需求 | 正常、峰值和异常场景是什么？哪些可降级？ | 指标、单位、起终点、来源 |
| 候选方案 | 哪两种方案可比较？硬约束先淘汰谁？ | 数据流、选型证据与未知 |
| 资源总账 | RAM、CPU、IO、功耗与停止预算怎样闭合？ | map、原始测量、预算表 |
| 接口契约 | 谁持有数据？何时接受、完成、取消和归还？ | API、状态机、身份与错误 |
| 复杂度 | 新 OS/芯片/功能影响哪些模块和组合？ | 依赖、锁序、支持矩阵 |
| 故障与恢复 | 谁选择恢复层级？失败如何终结？ | 故障树、次数、退避和诊断 |
| 发布与维护 | 集成、兼容、升级和供应替代怎样执行？ | 清单、回滚、责任与冻结点 |
| 最终决定 | 选择什么？什么条件会推翻它？ | 理由、剩余风险和下一次验证 |
用在途额度例子填一份决定¶
问题：模拟器约 5 ms 回复，4 个在途请求不能达到假设的 2000 requests/s。
候选：保留额度 4，或提高到 16。两者保持相同 payload、内容校验与终态规则；当前固定结构不随逻辑额度变化。
证据：2026-10-02/03 历史基准中，4 约 664 requests/s，16 约 2645 requests/s；成功样本 p99 均低于本文假设的 10 ms。固定结构和 owner 配置栈合计 393424 bytes，尚未包含完整 OS 与后端开销。
决定：采用 16 作为本教学流水线的吞吐候选，保留 4 做对照。完整目标 RAM、慢 callback、真实设备服务能力、故障期时延和功耗仍待验证。
退出条件：内容失败、p99 越界、RAM 越界、恢复恶化，或者设备改为串行执行。若要降低内存，改变结构或所有权方案并重新测量，不能只改逻辑额度。
约束变化以后重新展开¶
RAM 减半时，先查总账中哪些项可裁剪，再比较缩小池、减少副本和换平台；吞吐加倍时，先看流水线和瓶颈，再评估额度；供应替代时，重新计算改板、BSP、驱动、协议、验证和维护成本。
每次变化保留原决定的条件和证据，补充新的验证与回滚。这样局部机制、平台选择和交付责任能沿同一条问题链追踪。