Hi Matthew, On Fri, 22 Nov 2019, Matthew Wilcox wrote: > On Fri, Nov 22, 2019 at 06:44:39PM -0800, Paul Walmsley wrote: > > Documentation/riscv/patch-acceptance.rst | 32 ++++++++++++++++++++++++ > > 1 file changed, 32 insertions(+) > > create mode 100644 Documentation/riscv/patch-acceptance.rst > > Should this be linked into the toctree somewhere so it's findable > on kernel.org? Maybe add a line to Documentation/process/index.rst > to include ../riscv/patch-acceptance.rst? Does this updated patch contain what you had in mind? - Paul From: Paul Walmsley <paul.walmsley@xxxxxxxxxx> Date: Fri, 22 Nov 2019 18:33:28 -0800 Subject: [PATCH] Documentation: riscv: add patch acceptance guidelines 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. Based on a suggestion from Matthew Wilcox, we also add a link to this file to Documentation/process/index.rst, to make this document easier to find. Signed-off-by: Paul Walmsley <paul.walmsley@xxxxxxxxxx> Reviewed-by: Palmer Dabbelt <palmerdabbelt@xxxxxxxxxx> Cc: Palmer Dabbelt <palmer@xxxxxxxxxxx> Cc: Albert Ou <aou@xxxxxxxxxxxxxxxxx> Cc: Krste Asanovic <krste@xxxxxxxxxxxx> Cc: Andrew Waterman <waterman@xxxxxxxxxxxxxxxxx> Cc: Matthew Wilcox <willy@xxxxxxxxxxxxx> --- Documentation/process/index.rst | 1 + Documentation/riscv/index.rst | 1 + Documentation/riscv/patch-acceptance.rst | 32 ++++++++++++++++++++++++ 3 files changed, 34 insertions(+) create mode 100644 Documentation/riscv/patch-acceptance.rst diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst index e2c9ffc682c5..9b8394eacea6 100644 --- a/Documentation/process/index.rst +++ b/Documentation/process/index.rst @@ -58,6 +58,7 @@ lack of a better place. magic-number volatile-considered-harmful clang-format + ../riscv/patch-acceptance .. only:: subproject and html diff --git a/Documentation/riscv/index.rst b/Documentation/riscv/index.rst index 215fd3c1f2d5..fa33bffd8992 100644 --- a/Documentation/riscv/index.rst +++ b/Documentation/riscv/index.rst @@ -7,6 +7,7 @@ RISC-V architecture boot-image-header pmu + patch-acceptance .. only:: subproject and html 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