LIBNVDIMM 维护者入口配置

概述

libnvdimm 子系统管理跨多个架构的持久内存。邮件列表在此处由 patchwork 跟踪：https://patchwork.kernel.org/project/linux-nvdimm/list/ ...并且该实例配置为向提交者提供有关补丁接受和上游合并的反馈。补丁被合并到 ‘libnvdimm-fixes’ 或 ‘libnvdimm-for-next’ 分支。这些分支在此处可用：https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git/

通常，可以针对最新的 -rc 提交补丁；但是，如果传入的代码更改依赖于其他挂起的更改，则补丁应基于 libnvdimm-for-next 分支。但是，由于持久内存位于存储和内存的交汇处，因此在某些情况下，补丁更适合通过文件系统或内存管理树合并。如有疑问，请复制 nvdimm 列表，维护人员将帮助路由。

提交将暴露给 kbuild 机器人进行编译回归测试。在提交之前从该基础结构获得成功通知会有所帮助，但不是必需的。

提交清单附录

子系统通过 ndctl 实用程序进行单元测试：https://github.com/pmem/ndctl 这些测试需要在补丁向上游之前通过，但不一定在首次发布之前通过。如果您需要帮助设置测试环境，请联系列表。

ACPI 设备特定方法 (_DSM)

在考虑启用新的 _DSM 系列的补丁之前，必须从 ACPI 规范工作组的 NVDIMM 子团队分配格式接口代码。总的来说，子系统的立场是反对 NVDIMM 命令集的扩散，因此请强烈考虑实现对现有命令集的支持。有关支持的命令集，请参见 drivers/acpi/nfit/nfit.h。

关键周期日期

新提交可以随时发送，但如果它们打算进入下一个合并窗口，则应在 -rc4 之前发送，并且最好在 -rc6 之前在 libnvdimm-for-next 分支中稳定下来。当然，如果一个补丁集需要超过 2 周的审查，-rc4 就已经太晚了，一些补丁可能需要多个开发周期才能审查。

审查节奏

一般来说，请等待最多一周再进行反馈。首选私人邮件提醒。或者，请其他具有 libnvdimm 更改的 Reviewed-by 标签的开发人员查看并提供他们的意见。