| .. SPDX-License-Identifier: GPL-2.0 |
| |
| arch/riscv maintenance guidelines for developers |
| ================================================ |
| |
| Overview |
| -------- |
| 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. |
| |
| Submit Checklist Addendum |
| ------------------------- |
| 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.) |
