1 .. SPDX-License-Identifier: GPL-2.0-or-later 1 .. SPDX-License-Identifier: GPL-2.0-or-later
2 2
3 .. include:: ../disclaimer-zh_CN.rst 3 .. include:: ../disclaimer-zh_CN.rst
4 4
5 .. _cn_researcherguidelines: 5 .. _cn_researcherguidelines:
6 6
7 :Original: Documentation/process/researcher-gu 7 :Original: Documentation/process/researcher-guidelines.rst
8 8
9 :译者: 9 :译者:
10 - 慕冬亮 Dongliang Mu <dzm91@hust.edu.cn> 10 - 慕冬亮 Dongliang Mu <dzm91@hust.edu.cn>
11 11
12 研究人员指南 12 研究人员指南
13 +++++++++++++++++++++ 13 +++++++++++++++++++++
14 14
15 Linux 内核社区欢迎对 Linux 内核及其 15 Linux 内核社区欢迎对 Linux 内核及其开发过程中涉及的活动与任何其他副产品
16 进行透明的研究。Linux 从这种研究 16 进行透明的研究。Linux 从这种研究中受益匪浅，其多方面均由某种形式的研究所推动。
17 17
18 社区非常感谢研究人员在公开研究 18 社区非常感谢研究人员在公开研究结果之前能分享初步发现，特别是涉及安全的研究。
19 早期参与有助于提高研究质量并使 19 早期参与有助于提高研究质量并使 Linux 受益。无论如何，推荐研究人员与社区分享
20 已发表研究的开放访问副本。 20 已发表研究的开放访问副本。
21 21
22 本文旨在澄清研究开展过程中 Linux 22 本文旨在澄清研究开展过程中 Linux 内核社区认可与不认可的一些做法。至少，这类
23 研究及相关活动应遵循标准的研究 23 研究及相关活动应遵循标准的研究伦理规则。有关研究伦理、技术伦理以及开发者社区
24 研究的更多背景信息，请查阅： 24 研究的更多背景信息，请查阅：
25 25
26 * `研究伦理史 <https://www.unlv.edu/resea 26 * `研究伦理史 <https://www.unlv.edu/research/ORI-HSR/history-ethics>`_
27 * `IEEE 伦理 <https://www.ieee.org/about/eth 27 * `IEEE 伦理 <https://www.ieee.org/about/ethics/index.html>`_
28 * `开发者和研究人员对开源项目实 28 * `开发者和研究人员对开源项目实验伦理的看法 <https://arxiv.org/pdf/2112.13217.pdf>`_
29 29
30 Linux 内核社区期望与项目互动的每 30 Linux 内核社区期望与项目互动的每个人都是真诚地为了使 Linux 变得更好。
31 对 Linux 内核社区产生的任何公开可 31 对 Linux 内核社区产生的任何公开可用的成果（包括但不限于源代码）的研究
32 是受欢迎的，对开发者的研究如若 32 是受欢迎的，对开发者的研究如若要开展，则必须要明确说明，获得（开发者）同意。
33 33
34 完全基于公开可用资源（包括公共 34 完全基于公开可用资源（包括公共邮件列表的帖子和公开代码库的提交）的被动研究
35 显然是允许的。不过，和任何研究 35 显然是允许的。不过，和任何研究一样，仍需遵循标准伦理。
36 36
37 然而，针对开发者行为的主动研究 37 然而，针对开发者行为的主动研究必须在获得相关开发者的明确同意和完全披露的情况下进行。
38 未经同意，不得与开发者互动或对 38 未经同意，不得与开发者互动或对其进行实验；这也是标准的研究伦理。
39 39
40 调查 40 调查
41 ======= 41 =======
42 42
43 研究通常采用调查问卷的形式发送 43 研究通常采用调查问卷的形式发送给维护者或贡献者。然而，内核社区通常从这些调查问卷中获益
44 甚少。内核开发过程之所以有效， 44 甚少。内核开发过程之所以有效，是因为每个开发者都从中受益，即使与目标不同的人一起工作。
45 而回应调查则是对繁忙开发者的单 45 而回应调查则是对繁忙开发者的单向需求，对他们自己或整个内核社区没有相应的好处。因此，
46 这种研究方法不被鼓励。 46 这种研究方法不被鼓励。
47 47
48 内核社区成员已经收到过多的电子 48 内核社区成员已经收到过多的电子邮件，可能会将调查请求视为对他们时间的又一要求。发送
49 此类请求会剥夺社区宝贵的贡献者 49 此类请求会剥夺社区宝贵的贡献者时间，且不太可能产生有统计意义的回应。
50 50
51 作为替代，研究人员应考虑参加开 51 作为替代，研究人员应考虑参加开发者活动，举办研讨会来介绍研究项目及其对参与者的益处，
52 并直接与社区互动。该方式获得的 52 并直接与社区互动。该方式获得的信息将比电子邮件调查问卷丰富得多，且社区也能从中学习
53 到您的见解。 53 到您的见解。
54 54
55 补丁 55 补丁
56 ======= 56 =======
57 57
58 澄清：向开发者发送补丁**是**与他 58 澄清：向开发者发送补丁**是**与他们互动，但他们已经同意接收**善意贡献**。故意发送有缺陷/
59 有漏洞的补丁或在讨论中提供误导 59 有漏洞的补丁或在讨论中提供误导信息是不被同意的。这种交流会对开发者造成损害
60 （例如，消耗时间、精力和士气） 60 （例如，消耗时间、精力和士气），并通过破坏整个开发者社区对贡献者（及其所在组织）
61 的信任而损害项目，削弱为贡献者 61 的信任而损害项目，削弱为贡献者提供建设性反馈的努力，并使最终用户面临软件缺陷的风险。
62 62
63 研究人员参与 Linux 本身的开发与其 63 研究人员参与 Linux 本身的开发与其他人一样受到欢迎和鼓励。研究 Linux 代码是常见
64 做法，尤其是在开发或运行可产生 64 做法，尤其是在开发或运行可产生可操作结果的分析工具时。
65 65
66 在与开发者社区互动时，发送补丁 66 在与开发者社区互动时，发送补丁历来是产生影响的最佳方式。Linux 已经有很多已知的
67 漏洞 -- 更有帮助的是经过审核的修 67 漏洞 -- 更有帮助的是经过审核的修复。在贡献之前，请仔细阅读相关文档：
68 68
69 * Documentation/process/development-process.rs 69 * Documentation/process/development-process.rst
70 * Documentation/process/submitting-patches.rst 70 * Documentation/process/submitting-patches.rst
71 * Documentation/admin-guide/reporting-issues.r 71 * Documentation/admin-guide/reporting-issues.rst
72 * Documentation/process/security-bugs.rst 72 * Documentation/process/security-bugs.rst
73 73
74 然后发送补丁（包括所有如下详细 74 然后发送补丁（包括所有如下详细信息的提交日志）并跟进其他开发者的任何反馈。
75 75
76 当发送因研究而产生的补丁时，提 76 当发送因研究而产生的补丁时，提交日志应至少包含以下详细信息，以便开发者有适当的上下文
77 来理解贡献。回答： 77 来理解贡献。回答：
78 78
79 * 找到了什么具体问题？ 79 * 找到了什么具体问题？
80 * 在运行系统上如何触发这个问题 80 * 在运行系统上如何触发这个问题？
81 * 遇到这个问题对系统会有什么影 81 * 遇到这个问题对系统会有什么影响？
82 * 如何发现这个问题？具体包括任 82 * 如何发现这个问题？具体包括任何测试、静态或动态分析程序及其他用于执行工作的工具或方法的详细信息。
83 * 在哪个版本的 Linux 上发现了这个 83 * 在哪个版本的 Linux 上发现了这个问题？强烈推荐使用最新的发布版本或最近的 linux-next 分支（参见 Documentation/process/howto.rst）。
84 * 进行了哪些更改来修复这个问题 84 * 进行了哪些更改来修复这个问题，为什么认为这些更改是正确的？
85 * 如何进行构建测试和运行时测试 85 * 如何进行构建测试和运行时测试？
86 * 此更改修复了哪个先前的提交？ 86 * 此更改修复了哪个先前的提交？这应该在 "Fixes:" 标签中，如文档所述。
87 * 还有谁审查了这个补丁？这应该 87 * 还有谁审查了这个补丁？这应该在适当的 "Reviewed-by:" 标签中注明；见下文。
88 88
89 例如:: 89 例如::
90 90
91 From: Author <author@email> 91 From: Author <author@email>
92 Subject: [PATCH] drivers/foo_bar: Add missin 92 Subject: [PATCH] drivers/foo_bar: Add missing kfree()
93 93
94 The error path in foo_bar driver does not co 94 The error path in foo_bar driver does not correctly free the allocated
95 struct foo_bar_info. This can happen if the 95 struct foo_bar_info. This can happen if the attached foo_bar device
96 rejects the initialization packets sent duri 96 rejects the initialization packets sent during foo_bar_probe(). This
97 would result in a 64 byte slab memory leak o 97 would result in a 64 byte slab memory leak once per device attach,
98 wasting memory resources over time. 98 wasting memory resources over time.
99 99
100 This flaw was found using an experimental st 100 This flaw was found using an experimental static analysis tool we are
101 developing, LeakMagic[1], which reported the 101 developing, LeakMagic[1], which reported the following warning when
102 analyzing the v5.15 kernel release: 102 analyzing the v5.15 kernel release:
103 103
104 path/to/foo_bar.c:187: missing kfree() call 104 path/to/foo_bar.c:187: missing kfree() call?
105 105
106 Add the missing kfree() to the error path. N 106 Add the missing kfree() to the error path. No other references to
107 this memory exist outside the probe function 107 this memory exist outside the probe function, so this is the only
108 place it can be freed. 108 place it can be freed.
109 109
110 x86_64 and arm64 defconfig builds with CONFI 110 x86_64 and arm64 defconfig builds with CONFIG_FOO_BAR=y using GCC
111 11.2 show no new warnings, and LeakMagic no 111 11.2 show no new warnings, and LeakMagic no longer warns about this
112 code path. As we don't have a FooBar device 112 code path. As we don't have a FooBar device to test with, no runtime
113 testing was able to be performed. 113 testing was able to be performed.
114 114
115 [1] https://url/to/leakmagic/details 115 [1] https://url/to/leakmagic/details
116 116
117 Reported-by: Researcher <researcher@email> 117 Reported-by: Researcher <researcher@email>
118 Fixes: aaaabbbbccccdddd ("Introduce support 118 Fixes: aaaabbbbccccdddd ("Introduce support for FooBar")
119 Signed-off-by: Author <author@email> 119 Signed-off-by: Author <author@email>
120 Reviewed-by: Reviewer <reviewer@email> 120 Reviewed-by: Reviewer <reviewer@email>
121 121
122 如果您是第一次参与贡献，建议在 122 如果您是第一次参与贡献，建议在补丁在发布到公共列表前请其他人私下进行审核。（如果明确
123 告诉您补丁需要更仔细的内部审查 123 告诉您补丁需要更仔细的内部审查，则这是必需的。）这些人预计会在最终的补丁中包含他们的
124 "Reviewed-by" 标签。找到熟悉 Linux 贡 124 "Reviewed-by" 标签。找到熟悉 Linux 贡献的其他开发者，特别是您自己组织内的开发者，
125 并在将补丁发送到公共邮件列表前 125 并在将补丁发送到公共邮件列表前请他们帮助审核，往往会显著提高补丁的质量，从而减少
126 其他开发者的负担。 126 其他开发者的负担。
127 127
128 如果你找不到人内部审核补丁且需 128 如果你找不到人内部审核补丁且需要帮助找到这样的人，或者如果您对本文档和开发者社区的期望
129 有任何其他问题，请联系技术咨询< 129 有任何其他问题，请联系技术咨询委员会私有邮件列表：<tech-board@groups.linuxfoundation.org>。
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.