36 lines
1.7 KiB
ReStructuredText
36 lines
1.7 KiB
ReStructuredText
|
.. 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.)
|