研究人员指南¶
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>。