| 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 流程一起，可作为 RFC 流程（适用于 Zircon）的文档。
缺点、替代方案和未知因素
Fuchsia RFC 流程引入了可能会减缓决策制定和执行速度的摩擦。“何时使用此流程”部分中的条件试图通过将流程限定在重要情况下来缓解此问题，但这种限定必然会产生假正例和假负例。
在源代码库中记录决策会使这些决策更难更改。在某些情况下，这种影响可能是积极的，但在其他情况下，这种影响也可能是消极的。
在管理决策流程方面，还有许多可能的替代策略，但目前来看，与 Fuchsia RFC 流程及其在解决这些问题时的演变保持一致似乎是最好的前进方向。