| 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 流程保持一致并随着其解决这些问题而不断演变似乎是最佳方式。