maintainer-entry-profile.rst 2.6 KB

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