arch/riscv 开发人员维护指南¶
概述¶
RISC-V 指令集架构是开放开发的：正在进行的草案可供所有人审查并用于实验性实现。新的模块或扩展草案在开发过程中可能会发生变化 - 有时会以与以前的草案不兼容的方式进行更改。这种灵活性可能会给 RISC-V Linux 的维护带来挑战。Linux 维护人员不赞成频繁变动，并且 Linux 开发过程倾向于经过充分审查和测试的代码，而不是实验性代码。我们希望将相同的原则扩展到将被接受纳入内核的 RISC-V 相关代码。
Patchwork¶
RISC-V 有一个 patchwork 实例，可以在其中检查补丁的状态
如果您的补丁没有出现在默认视图中，则 RISC-V 维护人员可能已经要求更改，或者希望将其应用于另一个树。
自动化会针对此 patchwork 实例运行，在补丁到达时构建/测试补丁。自动化会将补丁应用于 RISC-V for-next 和 fixes 分支的当前 HEAD，具体取决于是否已检测到该补丁是修复程序。如果这些都失败，它将使用 RISC-V master 分支。一系列补丁应用的准确提交将会在 patchwork 上注明。任何检查失败的补丁都不太可能被应用，在大多数情况下都需要重新提交。
提交清单附录¶
只有当新模块或扩展的规范被列为在未来不太可能发生不兼容的更改时，我们才会接受这些模块或扩展的补丁。对于 RISC-V 基金会的规范，这意味着“冻结”或“批准”，对于 UEFI 论坛规范，这意味着已发布的 ECR。（当然，开发人员可以维护他们自己的 Linux 内核树，其中包含他们希望的任何草案扩展的代码。）
此外，RISC-V 规范允许实施者创建他们自己的自定义扩展。这些自定义扩展不需要经过 RISC-V 基金会的任何审查或批准流程。为了避免为特定于实施者的 RISC-V 扩展添加内核代码所带来的维护复杂性和潜在的性能影响，我们只会考虑以下扩展的补丁：
已由 RISC-V 基金会正式冻结或批准，或
已在广泛可用的硬件中实现，符合标准的 Linux 实践。
（当然，实施者可以维护他们自己的 Linux 内核树，其中包含他们希望的任何自定义扩展的代码。）