@@ -4,15 +4,15 @@ LIBNVDIMM Maintainer Entry Profile
4
4
Overview
5
5
--------
6
6
The libnvdimm subsystem manages persistent memory across multiple
7
- architectures. The mailing list, is tracked by patchwork here:
7
+ architectures. The mailing list is tracked by patchwork here:
8
8
https://patchwork.kernel.org/project/linux-nvdimm/list/
9
9
...and that instance is configured to give feedback to submitters on
10
10
patch acceptance and upstream merge. Patches are merged to either the
11
- 'libnvdimm-fixes', or 'libnvdimm-for-next' branch. Those branches are
11
+ 'libnvdimm-fixes' or 'libnvdimm-for-next' branch. Those branches are
12
12
available here:
13
13
https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git/
14
14
15
- In general patches can be submitted against the latest -rc, however if
15
+ In general patches can be submitted against the latest -rc; however, if
16
16
the incoming code change is dependent on other pending changes then the
17
17
patch should be based on the libnvdimm-for-next branch. However, since
18
18
persistent memory sits at the intersection of storage and memory there
@@ -35,20 +35,20 @@ getting the test environment set up.
35
35
36
36
ACPI Device Specific Methods (_DSM)
37
37
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
38
- Before patches enabling for a new _DSM family will be considered it must
38
+ Before patches enabling a new _DSM family will be considered, it must
39
39
be assigned a format-interface-code from the NVDIMM Sub-team of the ACPI
40
40
Specification Working Group. In general, the stance of the subsystem is
41
- to push back on the proliferation of NVDIMM command sets, do strongly
41
+ to push back on the proliferation of NVDIMM command sets, so do strongly
42
42
consider implementing support for an existing command set. See
43
- drivers/acpi/nfit/nfit.h for the set of support command sets.
43
+ drivers/acpi/nfit/nfit.h for the set of supported command sets.
44
44
45
45
46
46
Key Cycle Dates
47
47
---------------
48
48
New submissions can be sent at any time, but if they intend to hit the
49
49
next merge window they should be sent before -rc4, and ideally
50
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
51
+ patch set requires more than 2 weeks of review, -rc4 is already too late
52
52
and some patches may require multiple development cycles to review.
53
53
54
54
0 commit comments