요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. 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.
Patchwork
---------
RISC-V has a patchwork instance, where the status of patches can be checked:
https://patchwork.kernel.org/project/linux-riscv/list/
If your patch does not appear in the default view, the RISC-V maintainers have
likely either requested changes, or expect it to be applied to another tree.
Automation runs against this patchwork instance, building/testing patches as
they arrive. The automation applies patches against the current HEAD of the
RISC-V `for-next` and `fixes` branches, depending on whether the patch has been
detected as a fix. Failing those, it will use the RISC-V `master` branch.
The exact commit to which a series has been applied will be noted on patchwork.
Patches for which any of the checks fail are unlikely to be applied and in most
cases will need to be resubmitted.
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
unlikely to be incompatibly changed in the future. For
specifications from the RISC-V foundation this means "Frozen" or
"Ratified", for the UEFI forum specifications this means a published
ECR. (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 implementers 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 consider patches for extensions that either:
- Have been officially frozen or ratified by the RISC-V Foundation, or
- Have been implemented in hardware that is widely available, per standard
Linux practice.
(Implementers, may, of course, maintain their own Linux kernel trees containing
code for any custom extensions that they wish.)
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
Maintenance guideline 개요
1-17RISC-V ISA는 공개적으로 개발되어 진행 중인 draft도 누구나 검토하고 구현을 실험할 수 있습니다. 그러나 새 module이나 extension draft는 개발 중 이전 draft와 호환되지 않게 바뀔 수 있습니다.
이 유연성은 RISC-V Linux maintenance에 어려움을 줍니다. Linux maintainer는 불필요한 churn을 피하고 experimental code보다 충분히 review·test된 code를 선호하므로, kernel에 들어오는 RISC-V code에도 같은 원칙을 적용합니다.
Patchwork와 automation
18-35RISC-V patch 상태는 전용 patchwork instance에서 확인할 수 있습니다.
Patch가 default view에 없다면 maintainer가 변경을 요청했거나 다른 tree에 적용될 것으로 판단했을 가능성이 큽니다.
Automation은 patch가 도착할 때 build와 test를 실행합니다. Fix로 감지됐는지에 따라 현재 RISC-V `for-next` 또는 `fixes` branch HEAD에 적용하고, 둘 다 실패하면 RISC-V `master` branch를 사용합니다. Series가 적용된 정확한 commit은 patchwork에 기록됩니다.
검사 하나라도 실패한 patch는 적용될 가능성이 낮고 대개 수정해 다시 제출해야 합니다.
Patchwork에 들어온 series가 candidate branch와 검사 결과를 거치는 흐름입니다.
새 specification patch 조건
36-45새 module이나 extension patch는 specification이 앞으로 비호환 방식으로 바뀔 가능성이 낮다고 표시된 경우에만 받습니다. RISC-V Foundation specification은 `Frozen` 또는 `Ratified`, UEFI Forum specification은 published ECR이어야 합니다.
Developer가 원하는 draft extension code를 개인 Linux kernel tree에서 유지하는 것은 가능합니다.
Custom extension 조건
46-59RISC-V implementer는 Foundation의 review나 ratification을 거치지 않는 custom extension을 만들 수 있습니다. Implementer-specific extension code가 kernel maintenance 복잡도와 성능 영향을 늘리는 일을 피하기 위해 다음 둘 중 하나를 만족하는 patch만 검토합니다.
- RISC-V Foundation이 공식적으로 frozen 또는 ratified한 extension
- 일반 Linux 관행에 따라 널리 구할 수 있는 hardware에 구현된 extension
이 조건과 별개로 implementer는 원하는 custom extension code를 개인 Linux kernel tree에서 유지할 수 있습니다.
요약과 해설
patch-acceptance.rst:1-59Upstream kernel은 draft churn을 피하기 위해 Frozen/Ratified specification 또는 널리 보급된 hardware 구현을 요구합니다. Patchwork automation은 `for-next`, `fixes`, `master` 순으로 적용 가능성과 build/test 결과를 기록합니다.