61 lines · plain
1LIBNVDIMM Maintainer Entry Profile2==================================3 4Overview5--------6The libnvdimm subsystem manages persistent memory across multiple7architectures. 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 on10patch acceptance and upstream merge. Patches are merged to either the11'libnvdimm-fixes' or 'libnvdimm-for-next' branch. Those branches are12available 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, if16the incoming code change is dependent on other pending changes then the17patch should be based on the libnvdimm-for-next branch. However, since18persistent memory sits at the intersection of storage and memory there19are cases where patches are more suitable to be merged through a20Filesystem or the Memory Management tree. When in doubt copy the nvdimm21list and the maintainers will help route.22 23Submissions will be exposed to the kbuild robot for compile regression24testing. It helps to get a success notification from that infrastructure25before submitting, but it is not required.26 27 28Submit Checklist Addendum29-------------------------30There are unit tests for the subsystem via the ndctl utility:31https://github.com/pmem/ndctl32Those tests need to be passed before the patches go upstream, but not33necessarily before initial posting. Contact the list if you need help34getting the test environment set up.35 36ACPI Device Specific Methods (_DSM)37~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~38Before patches enabling a new _DSM family will be considered, it must39be assigned a format-interface-code from the NVDIMM Sub-team of the ACPI40Specification Working Group. In general, the stance of the subsystem is41to push back on the proliferation of NVDIMM command sets, so do strongly42consider implementing support for an existing command set. See43drivers/acpi/nfit/nfit.h for the set of supported command sets.44 45 46Key Cycle Dates47---------------48New submissions can be sent at any time, but if they intend to hit the49next merge window they should be sent before -rc4, and ideally50stabilized in the libnvdimm-for-next branch by -rc6. Of course if a51patch set requires more than 2 weeks of review, -rc4 is already too late52and some patches may require multiple development cycles to review.53 54 55Review Cadence56--------------57In general, please wait up to one week before pinging for feedback. A58private mail reminder is preferred. Alternatively ask for other59developers that have Reviewed-by tags for libnvdimm changes to take a60look and offer their opinion.61