LIBNVDIMM 유지관리자 항목 프로필 | Linux 6.18.37

요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.

1. 요약·해설

원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.

요약·해설

maintainer-entry-profile.rst:1-60

libnvdimm 변경은 의존성에 따라 최신 `-rc` 또는 `libnvdimm-for-next`를 기준으로 하고, upstream 전에는 ndctl unit test를 통과해야 합니다.

새 `_DSM` family에는 ACPI working group의 code 배정이 필요하며, 다음 merge window를 목표로 하면 `-rc4` 전 제출과 `-rc6` 안정화를 권장합니다.

2. 영어 원문 전체

번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.

원문 전체 펼치기

1 LIBNVDIMM Maintainer Entry Profile

2 ==================================

4 Overview

5 --------

6 The libnvdimm subsystem manages persistent memory across multiple

7 architectures. The mailing list is tracked by patchwork here:

8 https://patchwork.kernel.org/project/linux-nvdimm/list/

9 ...and that instance is configured to give feedback to submitters on

10 patch acceptance and upstream merge. Patches are merged to either the

11 'libnvdimm-fixes' or 'libnvdimm-for-next' branch. Those branches are

12 available here:

13 https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git/

15 In general patches can be submitted against the latest -rc; however, if

16 the incoming code change is dependent on other pending changes then the

17 patch should be based on the libnvdimm-for-next branch. However, since

18 persistent memory sits at the intersection of storage and memory there

19 are cases where patches are more suitable to be merged through a

20 Filesystem or the Memory Management tree. When in doubt copy the nvdimm

21 list and the maintainers will help route.

23 Submissions will be exposed to the kbuild robot for compile regression

24 testing. It helps to get a success notification from that infrastructure

25 before submitting, but it is not required.

28 Submit Checklist Addendum

29 -------------------------

30 There are unit tests for the subsystem via the ndctl utility:

31 https://github.com/pmem/ndctl

32 Those tests need to be passed before the patches go upstream, but not

33 necessarily before initial posting. Contact the list if you need help

34 getting the test environment set up.

36 ACPI Device Specific Methods (_DSM)

37 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

38 Before patches enabling a new _DSM family will be considered, it must

39 be assigned a format-interface-code from the NVDIMM Sub-team of the ACPI

40 Specification Working Group. In general, the stance of the subsystem is

41 to push back on the proliferation of NVDIMM command sets, so do strongly

42 consider implementing support for an existing command set. See

43 drivers/acpi/nfit/nfit.h for the set of supported command sets.

46 Key Cycle Dates

47 ---------------

48 New submissions can be sent at any time, but if they intend to hit the

49 next merge window they should be sent before -rc4, and ideally

50 stabilized in the libnvdimm-for-next branch by -rc6. Of course if a

51 patch set requires more than 2 weeks of review, -rc4 is already too late

52 and some patches may require multiple development cycles to review.

55 Review Cadence

56 --------------

57 In general, please wait up to one week before pinging for feedback. A

58 private mail reminder is preferred. Alternatively ask for other

59 developers that have Reviewed-by tags for libnvdimm changes to take a

60 look and offer their opinion.

3. 한국어 전문 번역

영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.

개요와 patch 경로

1-27

libnvdimm subsystem은 여러 architecture의 persistent memory를 관리합니다. Mailing list는 `https://patchwork.kernel.org/project/linux-nvdimm/list/`의 patchwork에서 추적하며, submitter에게 patch 채택과 upstream merge 결과를 알리도록 구성돼 있습니다.

Patch는 `libnvdimm-fixes` 또는 `libnvdimm-for-next` branch로 merge되며 저장소는 `https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git/`입니다.

일반적으로 최신 `-rc`를 기준으로 patch를 제출할 수 있습니다. 아직 merge되지 않은 다른 변경에 의존한다면 `libnvdimm-for-next` branch를 기준으로 삼아야 합니다.

Persistent memory는 storage와 memory의 경계에 있으므로 Filesystem tree나 Memory Management tree를 통해 merge하는 편이 적절할 때도 있습니다. 판단이 어렵다면 nvdimm list를 참조에 넣으면 maintainer가 경로를 안내합니다.

제출물은 compile regression을 찾는 kbuild robot 시험을 받습니다. 제출 전에 이 infrastructure의 성공 알림을 받으면 도움이 되지만 필수는 아닙니다.

LIBNVDIMM Maintainer Entry Profile
==================================

Overview
--------
The libnvdimm subsystem manages persistent memory across multiple
architectures. The mailing list is tracked by patchwork here:
https://patchwork.kernel.org/project/linux-nvdimm/list/
...and that instance is configured to give feedback to submitters on
patch acceptance and upstream merge. Patches are merged to either the
'libnvdimm-fixes' or 'libnvdimm-for-next' branch. Those branches are
available here:
https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git/

In general patches can be submitted against the latest -rc; however, if
the incoming code change is dependent on other pending changes then the
patch should be based on the libnvdimm-for-next branch. However, since
persistent memory sits at the intersection of storage and memory there
are cases where patches are more suitable to be merged through a
Filesystem or the Memory Management tree. When in doubt copy the nvdimm
list and the maintainers will help route.

Submissions will be exposed to the kbuild robot for compile regression
testing. It helps to get a success notification from that infrastructure
before submitting, but it is not required.

제출 checklist 추가 사항

28-35

Subsystem unit test는 `https://github.com/pmem/ndctl`의 ndctl utility로 실행합니다. Upstream에 들어가기 전에는 이 시험을 통과해야 하지만 최초 posting 전부터 반드시 통과할 필요는 없습니다.

시험 환경 설정에 도움이 필요하면 mailing list에 문의합니다.

Submit Checklist Addendum
-------------------------
There are unit tests for the subsystem via the ndctl utility:
https://github.com/pmem/ndctl
Those tests need to be passed before the patches go upstream, but not
necessarily before initial posting. Contact the list if you need help
getting the test environment set up.

ACPI Device Specific Methods(_DSM)

36-45

새 `_DSM` family를 활성화하는 patch를 검토하려면 먼저 ACPI Specification Working Group의 NVDIMM Sub-team에서 `format-interface-code`를 배정받아야 합니다.

Subsystem은 NVDIMM command set의 무분별한 증가를 억제하는 입장입니다. 새 command set을 만들기 전에 기존 command set 지원으로 구현할 수 있는지 진지하게 검토해야 합니다. 지원되는 command set은 `drivers/acpi/nfit/nfit.h`에 나옵니다.

ACPI Device Specific Methods (_DSM)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Before patches enabling a new _DSM family will be considered, it must
be assigned a format-interface-code from the NVDIMM Sub-team of the ACPI
Specification Working Group. In general, the stance of the subsystem is
to push back on the proliferation of NVDIMM command sets, so do strongly
consider implementing support for an existing command set. See
drivers/acpi/nfit/nfit.h for the set of supported command sets.

주요 개발 주기 시점

46-54

새 제출물은 언제든 보낼 수 있지만 다음 merge window에 들어가려면 `-rc4` 전에 보내고, 가능하면 `-rc6`까지 `libnvdimm-for-next` branch에서 안정화해야 합니다.

검토에 2주보다 오래 걸리는 patch set이라면 `-rc4`도 이미 늦습니다. 일부 patch는 검토에 여러 개발 cycle이 필요할 수 있습니다.

Key Cycle Dates
---------------
New submissions can be sent at any time, but if they intend to hit the
next merge window they should be sent before -rc4, and ideally
stabilized in the libnvdimm-for-next branch by -rc6. Of course if a
patch set requires more than 2 weeks of review, -rc4 is already too late
and some patches may require multiple development cycles to review.

검토 주기

55-60

Feedback을 다시 요청하기 전에는 일반적으로 최대 1주를 기다립니다. 공개 ping보다는 private mail reminder가 권장됩니다.

또는 과거 libnvdimm 변경에 `Reviewed-by` tag를 남긴 다른 developer에게 검토와 의견을 요청할 수 있습니다.

Review Cadence
--------------
In general, please wait up to one week before pinging for feedback. A
private mail reminder is preferred. Alternatively ask for other
developers that have Reviewed-by tags for libnvdimm changes to take a
look and offer their opinion.