| RFC-0006：Zircon 的 RFC 流程附录 | |
|---|---|
| 状态 | 已接受 |
| 领域 |
|
| 说明 | 使用适用于 Zircon 的 Fuchsia RFC 流程时的特殊注意事项。 |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2020-08-17 |
| 审核日期（年-月-日） | 2020-09-25 |
总结
本文档提出了对 Fuchsia RFC 流程的优化，以考虑 Zircon 代码库所面临的挑战。具体而言，对 Zircon 做出的更改符合下述一个（或多个）条件必须遵循 RFC 流程才能被接受。
设计初衷
目前，Zircon 使用临时流程进行系统级更改，但现在 Fuchsia 拥有明确的 RFC 流程，Zircon 应遵循该流程。不过，鉴于 Zircon 位于软件堆栈的最底部，与靠近项目分支的代码（例如，显著增加依赖关系图或如何平衡内存用量与性能）相比，它对某些类型的更改更敏感。
设计
对 Zircon 的绝大多数更改都不需要 RFC，只需进行代码审核即可。但是，除了 Fuchsia RFC 流程中列出的注意事项外，源目录中还存在以下更改：
- /zircon
- /src/zircon
- /src/bringup
时，必须使用 RFC 流程：
添加或移除 Zircon 系统接口。系统调用接口、关联的结构和常量是整个系统的标准答案，其影响不仅局限于 Zircon 本身，而且在实现之前需要广泛共识。
更改资源处理行为。系统如何处理资源（如内存、I/O、处理器时间或功耗）的分区或虚拟化，以及资源超额订阅或稀缺时执行的操作。
修改隔离保证。同等任务中私密和隔离的内容如何、彼此独立，以及特权任务可以观察和修改哪些特权任务。此处的更改需要通过此流程与安全团队协商批准。
性能或内存使用的重大变更。有时，如果添加了额外的安全性、监控或功能，性能会相应地下降或内存使用量增加，而这需要通过此流程进行审核。
倾向于使用单个平台。Zircon 力求在所有支持的架构和开发板上提供相同的功能和服务基准。如果变更利用一种平台功能，但在其他支持的平台上不可行或不可行，则需要采用此流程。
添加或降级对平台的支持。添加新的开发板或架构，或者废弃/减少对现有平台的支持都需要通过此流程进行审核。
新的 build 配置。添加新的 build 配置会增加整个项目的开发和测试负担，并且需要预先进行审核。
依赖关系图显著增大。Zircon 依赖项会影响整个项目，并且会发生重大变化。例如，如果新依赖项本身具有重要依赖项或本身很大，应使用 RFC 流程。
其他可能受益于 RFC 流程的更改是需要手动或自动对代码库进行大规模更改的更改。例如，如何写入日志或如何处理错误路径。我们的目标是找到最佳模式并将其统一应用于整个代码库，而不是孤立地生活。
文档
此 RFC 和 Fuchsia RFC 流程是适用于 Zircon 的 RFC 流程文档。
缺点、替代方案和未知情况
Fuchsia RFC 过程会出现阻力，可能会减慢制定和执行决策的速度。“何时使用此流程”部分中的标准尝试通过将流程限定为继发情况来缓解这个问题，但此类范围必定存在假正例和假负例。
在源代码库中记录决策会使其更难以更改。这种影响在某些情况下可能是积极的，但在其他情况下也可能是负面影响。
管理决策过程有许多可能的替代策略，但与 Fuchsia RFC 流程及其演变保持一致，因为它解决了这些问题，因此这似乎是目前的最佳方式。