研究人员指南¶
Linux 内核社区欢迎对 Linux 内核、其开发活动以及任何其他开发副产品进行透明研究。Linux 从这类研究中受益匪浅，Linux 的大多数方面都以这样或那样的形式受到研究的驱动。
如果研究人员能在公开发布成果之前分享初步发现，社区将不胜感激，尤其是在此类研究涉及安全的情况下。及早参与有助于提高研究质量，并使 Linux 从中获益。无论如何，建议与社区分享已发表研究的开放获取副本。
本文旨在阐明 Linux 内核社区在进行此类研究时，认为哪些做法是可接受的，哪些是不可接受的。至少，此类研究及相关活动应遵循标准的研究伦理规则。有关研究伦理（通常）、技术伦理以及特别是开发者社区研究的更多背景信息，请参阅
Linux 内核社区期望所有与项目互动的人都本着善意参与，以使 Linux 变得更好。欢迎对 Linux 内核社区产生的任何公开可用的工件（包括但不限于源代码）进行研究，但对开发人员的研究必须明确选择加入。
完全基于公开可用来源的被动研究，包括公共邮件列表上的帖子和公共仓库中的提交，显然是允许的。然而，与任何研究一样，仍然必须遵循标准的伦理规范。
然而，对开发者行为的主动研究，必须征得相关开发者的明确同意并向其充分披露。未经同意，不能与开发者互动/对开发者进行实验；这也是标准的研究伦理。
调查¶
研究通常采取向维护者或贡献者发送调查问卷的形式。然而，一般来说，内核社区从这些调查中获得的价值甚微。内核开发流程之所以有效，是因为每个开发人员都从他们的参与中受益，即使是与有不同目标的人合作。然而，回应调查问卷是对忙碌的开发人员提出的单向要求，对他们自己或整个内核社区都没有相应的益处。因此，不鼓励这种研究方法。
内核社区成员已经收到过多的电子邮件，并且很可能将调查请求视为对他们时间的又一个要求。发送此类请求会剥夺社区宝贵的贡献者时间，并且不太可能产生具有统计学意义的有用回复。
作为替代方案，研究人员应考虑参加开发者活动，举办会议以解释研究项目及其对参与者的益处，并直接与社区进行互动。这样获得的信息将比通过电子邮件调查获得的信息丰富得多，而且社区也将能够从您的见解中学习并受益。
补丁¶
为了澄清：向开发者发送补丁确实是与他们互动，但他们已经同意接收善意的贡献。发送故意有缺陷/易受攻击的补丁或在讨论中提供误导性信息是不被允许的。此类交流可能损害开发者（例如，耗费时间、精力并打击士气），并通过侵蚀整个开发者社区对贡献者（以及贡献者所属组织）的信任，从而损害项目，破坏向贡献者提供建设性反馈的努力，并使最终用户面临软件缺陷的风险。
研究人员参与 Linux 本身的开发，与任何人一样，是受到欢迎和鼓励的。对 Linux 代码的研究是一种常见做法，特别是在开发或运行能够产生可操作结果的分析工具时。
在与开发者社区互动时，发送补丁传统上是产生影响的最佳方式。Linux 已经存在许多已知错误——更有帮助的是拥有经过验证的修复方案。在贡献之前，请仔细阅读相关文档
然后发送补丁（包括带有以下所有详细信息的提交日志），并跟进其他开发人员的任何反馈。
发送研究产生的补丁时，提交日志应至少包含以下详细信息，以便开发者有适当的上下文来理解贡献。回答
发现了什么具体问题？
在运行的系统上如何复现此问题？
遇到此问题会对系统产生什么影响？
问题是如何发现的？具体包括有关任何测试、静态或动态分析程序以及用于执行此工作的任何其他工具或方法的详细信息。
问题是在哪个 Linux 版本上发现的？强烈建议使用最新发布版本或最新的 linux-next 分支（参见如何进行 Linux 内核开发）。
为修复此问题做了哪些更改，以及为什么认为这些更改是正确的？
此更改是如何进行构建测试和运行时测试的？
此更改修复了哪个之前的提交？这应如文档所述，放在“Fixes:”标签中。
还有谁审查过此补丁？这应放在相应的“Reviewed-by:”标签中；详见下文。
例如
From: Author <author@email>
Subject: [PATCH] drivers/foo_bar: Add missing kfree()
The error path in foo_bar driver does not correctly free the allocated
struct foo_bar_info. This can happen if the attached foo_bar device
rejects the initialization packets sent during foo_bar_probe(). This
would result in a 64 byte slab memory leak once per device attach,
wasting memory resources over time.
This flaw was found using an experimental static analysis tool we are
developing, LeakMagic[1], which reported the following warning when
analyzing the v5.15 kernel release:
path/to/foo_bar.c:187: missing kfree() call?
Add the missing kfree() to the error path. No other references to
this memory exist outside the probe function, so this is the only
place it can be freed.
x86_64 and arm64 defconfig builds with CONFIG_FOO_BAR=y using GCC
11.2 show no new warnings, and LeakMagic no longer warns about this
code path. As we don't have a FooBar device to test with, no runtime
testing was able to be performed.
[1] https://url/to/leakmagic/details
Reported-by: Researcher <researcher@email>
Fixes: aaaabbbbccccdddd ("Introduce support for FooBar")
Signed-off-by: Author <author@email>
Reviewed-by: Reviewer <reviewer@email>
如果您是首次贡献者，建议在将补丁发布到公共列表之前，先由他人在内部私下审查。（如果您已被明确告知您的补丁需要更仔细的内部审查，则这是必需的。）这些审查人员的“Reviewed-by”标签应包含在生成的补丁中。寻找另一位熟悉 Linux 贡献的开发者，尤其是在您自己的组织内部，并在将补丁发送到公共邮件列表之前让他们协助审查，这通常会显著提高补丁的质量，从而减轻其他开发者的负担。
如果没有人可以内部审查补丁并且您需要帮助寻找这样的人，或者您对本文档和开发者社区的期望有任何其他疑问，请联系私人技术咨询委员会邮件列表：<tech-board@groups.linuxfoundation.org>。