cachepc-linux

Fork of AMDESE/linux with modifications for CachePC side-channel attack
git clone https://git.sinitax.com/sinitax/cachepc-linux
Log | Files | Refs | README | LICENSE | sfeed.txt

patch-acceptance.rst (1729B)


      1.. SPDX-License-Identifier: GPL-2.0
      2
      3arch/riscv maintenance guidelines for developers
      4================================================
      5
      6Overview
      7--------
      8The RISC-V instruction set architecture is developed in the open:
      9in-progress drafts are available for all to review and to experiment
     10with implementations.  New module or extension drafts can change
     11during the development process - sometimes in ways that are
     12incompatible with previous drafts.  This flexibility can present a
     13challenge for RISC-V Linux maintenance.  Linux maintainers disapprove
     14of churn, and the Linux development process prefers well-reviewed and
     15tested code over experimental code.  We wish to extend these same
     16principles to the RISC-V-related code that will be accepted for
     17inclusion in the kernel.
     18
     19Submit Checklist Addendum
     20-------------------------
     21We'll only accept patches for new modules or extensions if the
     22specifications for those modules or extensions are listed as being
     23"Frozen" or "Ratified" by the RISC-V Foundation.  (Developers may, of
     24course, maintain their own Linux kernel trees that contain code for
     25any draft extensions that they wish.)
     26
     27Additionally, the RISC-V specification allows implementors to create
     28their own custom extensions.  These custom extensions aren't required
     29to go through any review or ratification process by the RISC-V
     30Foundation.  To avoid the maintenance complexity and potential
     31performance impact of adding kernel code for implementor-specific
     32RISC-V extensions, we'll only to accept patches for extensions that
     33have been officially frozen or ratified by the RISC-V Foundation.
     34(Implementors, may, of course, maintain their own Linux kernel trees
     35containing code for any custom extensions that they wish.)