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