Formalize, in kernel documentation, the patch acceptance policy for arch/riscv. In summary, it states that as maintainers, we plan to only accept patches for new modules or extensions that have been frozen or ratified by the RISC-V Foundation. We've been following these guidelines for the past few months. In the meantime, we've received quite a bit of feedback that it would be helpful to have these guidelines formally documented. Signed-off-by: Paul Walmsley <paul.walmsley@xxxxxxxxxx> Cc: Palmer Dabbelt <palmer@xxxxxxxxxxx> Cc: Albert Ou <aou@xxxxxxxxxxxxxxxxx> Cc: Krste Asanovic <krste@xxxxxxxxxxxx> Cc: Andrew Waterman <waterman@xxxxxxxxxxxxxxxxx> --- Documentation/riscv/patch-acceptance.rst | 32 ++++++++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 Documentation/riscv/patch-acceptance.rst diff --git a/Documentation/riscv/patch-acceptance.rst b/Documentation/riscv/patch-acceptance.rst new file mode 100644 index 000000000000..2e658353b53c --- /dev/null +++ b/Documentation/riscv/patch-acceptance.rst @@ -0,0 +1,32 @@ +.. SPDX-License-Identifier: GPL-2.0 + +==================================================== +arch/riscv maintenance and the RISC-V specifications +==================================================== + +The RISC-V instruction set architecture is developed in the open: +in-progress drafts are available for all to review and to experiment +with implementations. New module or extension drafts can change +during the development process - sometimes in ways that are +incompatible with previous drafts. This flexibility can present a +challenge for RISC-V Linux maintenance. Linux maintainers disapprove +of churn, and the Linux development process prefers well-reviewed and +tested code over experimental code. We wish to extend these same +principles to the RISC-V-related code that will be accepted for +inclusion in the kernel. + +Therefore, as maintainers, we'll only accept patches for new modules +or extensions if the specifications for those modules or extensions +are listed as being "Frozen" or "Ratified" by the RISC-V Foundation. +(Developers may, of course, maintain their own Linux kernel trees that +contain code for any draft extensions that they wish.) + +Additionally, the RISC-V specification allows implementors to create +their own custom extensions. These custom extensions aren't required +to go through any review or ratification process by the RISC-V +Foundation. To avoid the maintenance complexity and potential +performance impact of adding kernel code for implementor-specific +RISC-V extensions, we'll only to accept patches for extensions that +have been officially frozen or ratified by the RISC-V Foundation. +(Implementors, may, of course, maintain their own Linux kernel trees +containing code for any custom extensions that they wish.) -- 2.24.0.rc0
