1 LIBNVDIMM Maintainer Entry Profile 1 LIBNVDIMM Maintainer Entry Profile
2 ================================== 2 ==================================
3 3
4 Overview 4 Overview
5 -------- 5 --------
6 The libnvdimm subsystem manages persistent mem 6 The libnvdimm subsystem manages persistent memory across multiple
7 architectures. The mailing list is tracked by !! 7 architectures. The mailing list, is tracked by patchwork here:
8 https://patchwork.kernel.org/project/linux-nvd 8 https://patchwork.kernel.org/project/linux-nvdimm/list/
9 ...and that instance is configured to give fee 9 ...and that instance is configured to give feedback to submitters on
10 patch acceptance and upstream merge. Patches a 10 patch acceptance and upstream merge. Patches are merged to either the
11 'libnvdimm-fixes' or 'libnvdimm-for-next' bran !! 11 'libnvdimm-fixes', or 'libnvdimm-for-next' branch. Those branches are
12 available here: 12 available here:
13 https://git.kernel.org/pub/scm/linux/kernel/gi 13 https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git/
14 14
15 In general patches can be submitted against th !! 15 In general patches can be submitted against the latest -rc, however if
16 the incoming code change is dependent on other 16 the incoming code change is dependent on other pending changes then the
17 patch should be based on the libnvdimm-for-nex 17 patch should be based on the libnvdimm-for-next branch. However, since
18 persistent memory sits at the intersection of 18 persistent memory sits at the intersection of storage and memory there
19 are cases where patches are more suitable to b 19 are cases where patches are more suitable to be merged through a
20 Filesystem or the Memory Management tree. When 20 Filesystem or the Memory Management tree. When in doubt copy the nvdimm
21 list and the maintainers will help route. 21 list and the maintainers will help route.
22 22
23 Submissions will be exposed to the kbuild robo 23 Submissions will be exposed to the kbuild robot for compile regression
24 testing. It helps to get a success notificatio 24 testing. It helps to get a success notification from that infrastructure
25 before submitting, but it is not required. 25 before submitting, but it is not required.
26 26
27 27
28 Submit Checklist Addendum 28 Submit Checklist Addendum
29 ------------------------- 29 -------------------------
30 There are unit tests for the subsystem via the 30 There are unit tests for the subsystem via the ndctl utility:
31 https://github.com/pmem/ndctl 31 https://github.com/pmem/ndctl
32 Those tests need to be passed before the patch 32 Those tests need to be passed before the patches go upstream, but not
33 necessarily before initial posting. Contact th 33 necessarily before initial posting. Contact the list if you need help
34 getting the test environment set up. 34 getting the test environment set up.
35 35
36 ACPI Device Specific Methods (_DSM) 36 ACPI Device Specific Methods (_DSM)
37 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 37 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
38 Before patches enabling a new _DSM family will !! 38 Before patches enabling for a new _DSM family will be considered it must
39 be assigned a format-interface-code from the N 39 be assigned a format-interface-code from the NVDIMM Sub-team of the ACPI
40 Specification Working Group. In general, the s 40 Specification Working Group. In general, the stance of the subsystem is
41 to push back on the proliferation of NVDIMM co !! 41 to push back on the proliferation of NVDIMM command sets, do strongly
42 consider implementing support for an existing 42 consider implementing support for an existing command set. See
43 drivers/acpi/nfit/nfit.h for the set of suppor !! 43 drivers/acpi/nfit/nfit.h for the set of support command sets.
44 44
45 45
46 Key Cycle Dates 46 Key Cycle Dates
47 --------------- 47 ---------------
48 New submissions can be sent at any time, but i 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 - 49 next merge window they should be sent before -rc4, and ideally
50 stabilized in the libnvdimm-for-next branch by 50 stabilized in the libnvdimm-for-next branch by -rc6. Of course if a
51 patch set requires more than 2 weeks of review !! 51 patch set requires more than 2 weeks of review -rc4 is already too late
52 and some patches may require multiple developm 52 and some patches may require multiple development cycles to review.
53 53
54 54
55 Review Cadence 55 Review Cadence
56 -------------- 56 --------------
57 In general, please wait up to one week before 57 In general, please wait up to one week before pinging for feedback. A
58 private mail reminder is preferred. Alternativ 58 private mail reminder is preferred. Alternatively ask for other
59 developers that have Reviewed-by tags for libn 59 developers that have Reviewed-by tags for libnvdimm changes to take a
60 look and offer their opinion. 60 look and offer their opinion.
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.