1 .. SPDX-License-Identifier: GPL-2.0
2
3 .. _tw_process_howto:
4
5 .. include:: ../disclaimer-zh_TW.rst
6
7 :Original: :ref:`Documentation/process/howto.r
8
9 譯者::
10
11 英文版維護者： Greg Kroah-Hartman <g
12 中文版維護者： 李陽 Li Yang <leoy
13 中文版翻譯者： 李陽 Li Yang <leoy
14 時奎亮 Alex Shi <alex.shi
15 中文版校譯者:
16 鍾宇 TripleX Chung <xxx.p
17 陳琦 Maggie Chen <chenqi@
18 王聰 Wang Cong <xiyou.wan
19 胡皓文 Hu Haowen <2023002
20
21 如何參與Linux內核開發
22 =====================
23
24 這是一篇將如何參與Linux內核開發
25 成爲一名Linux內核開發者，並且學
26 包括任何關於內核編程的技術細節
27
28 如果這篇文章中的任何內容不再適
29
30
31 入門
32 ----
33
34 你想了解如何成爲一名Linux內核開
35 驅動程序」？這篇文章的目的就是
36 要經過的流程以及給出如何同內核
37 爲何這樣運作。
38
39 Linux內核大部分是由C語言寫成的，
40 參與內核開發，你必須精通C語言。
41 不需要了解（任何體系結構的）彙
42 語言教育和多年的開發經驗，但如
43
44 - "The C Programming Language" by Kernighan a
45 《C程序設計語言（第2版·新版）
46 - "Practical C Programming" by Steve Oualline
47 《實用C語言編程（第三版）》（
48 - "C: A Reference Manual" by Harbison and St
49 《C語言參考手冊（原書第5版）
50
51 Linux內核使用GNU C和GNU工具鏈開發。
52 標準中沒有定義的擴展。內核是自
53 並不支持C標準中的部分定義。比如
54 使用。有時候確實很難弄清楚內核
55 前還沒有明確的參考資料可以解釋
56 顯示）獲得一些這方面信息。
57
58 請記住你是在學習怎麼和已經存在
59 他們對代碼、風格和過程有著很高
60 適應於地理上分散的大型開發團隊
61 之前儘可能多的學習這些標準，而
62
63
64 法律問題
65 --------
66
67 Linux內核原始碼都是在GPL（通用公
68 的細節請查看原始碼主目錄下的COPY
69 `SPDX <https://spdx.org/>` 標誌符說明在
70 :ref:`Documentation/translations/zh_TW/process
71 如果你對它還有更深入問題請聯繫
72 郵件組裡的人並不是律師，不要期
73
74 對於GPL的常見問題和解答，請訪問
75 https://www.gnu.org/licenses/gpl-faq.h
76
77
78 文檔
79 ----
80
81 Linux內核代碼中包含有大量的文檔
82 不可估量的價值。當一個新的功能
83 檔也放進內核。當內核的改動導致
84 息或手冊頁(manpages)的補丁發到mtk.ma
85 的維護者解釋這些變化。
86
87 以下是內核代碼中需要閱讀的文檔
88 :ref:`Documentation/admin-guide/README.rst <
89 文件簡要介紹了Linux內核的背景
90 新用戶應該從這裡開始。
91
92
93 :ref:`Documentation/process/changes.rst <cha
94 文件給出了用來編譯和使用內核
95
96 :ref:`Documentation/translations/zh_TW/proce
97 描述Linux內核的代碼風格和理由
98 范。大多數維護者只會接收符合
99 的代碼。
100
101 :ref:`Documentation/translations/zh_TW/proce
102
103 這兩份文檔明確描述如何創建和
104 - 郵件內容
105 - 郵件格式
106 - 選擇收件人
107
108 遵守這些規定並不能保證提交成
109 審查），但是忽視他們幾乎就意
110
111 其他關於如何正確地生成補丁的
112 "The Perfect Patch"
113
114 https://www.ozlabs.org/~akpm/stuff/tpp
115
116 "Linux kernel patch submission format"
117
118 https://web.archive.org/web/2018082911
119
120 :ref:`Documentation/translations/zh_TW/proce
121 論證內核爲什麼特意不包括穩定
122 性：
123
124 - 子系統中間層（爲了兼容性
125 - 在不同作業系統間易於移植
126 - 減緩（甚至阻止）內核代碼
127
128 這篇文檔對於理解Linux的開發哲
129 統轉移到Linux的人來說也很重要
130
131 :ref:`Documentation/process/security-bugs.rs
132 如果你認爲自己發現了Linux內核
133 提醒其他內核開發者並幫助解決
134
135 :ref:`Documentation/translations/zh_TW/proce
136
137 描述內核維護者的工作方法及其
138 它感到好奇）的人來說很重要，
139 普遍誤解與迷惑。
140
141 :ref:`Documentation/process/stable-kernel-ru
142 解釋了穩定版內核發布的規則，
143
144 :ref:`Documentation/process/kernel-docs.rst
145 有助於內核開發的外部文檔列表
146 的內容，可以查看這些文檔。
147
148 :ref:`Documentation/process/applying-patches
149 關於補丁是什麼以及如何將它打
150
151 內核還擁有大量從代碼自動生成或
152 比如這個文檔，它包含內核內部API
153 這些文檔都可以通過運行以下命令
154
155 make pdfdocs
156 make htmldocs
157
158 ReST格式的文檔會生成在 Documentation/
159 它們也可以用下列命令生成 LaTeX 和
160
161 make latexdocs
162 make epubdocs
163
164 如何成爲內核開發者
165 ------------------
166 如果你對Linux內核開發一無所知，
167
168 https://kernelnewbies.org
169
170 它擁有一個可以問各種最基本的內
171 查找已往的郵件，確認是否有人已
172 實時反饋的IRC聊天頻道，以及大量
173
174 網站簡要介紹了原始碼組織結構、
175 中的和單獨維護的）。它還提供了
176 丁。
177
178 如果你想加入內核開發社區並協助
179 「Linux內核房管員」計劃：
180
181 https://kernelnewbies.org/KernelJanito
182
183 這是極佳的起點。它提供一個相對
184 整理或者改正的地方。通過和負責
185 集成進內核的基本原理。如果還沒
186 向性的指點。
187
188 在真正動手修改內核代碼之前，理
189 目的，沒什麼辦法比直接讀代碼更
190 一些特製的工具還可以提供幫助。
191 特別推薦的幫助工具，它將原始碼
192 時的內核源碼庫，可以通過以下地
193
194 https://elixir.bootlin.com/
195
196
197 開發流程
198 --------
199
200 目前Linux內核開發流程包括幾個「
201 些分支包括：
202
203 - Linus 的內核源碼樹
204 - 多個主要版本的穩定版內核樹
205 - 子系統相關的內核樹
206 - linux-next 集成測試樹
207
208
209 主線樹
210 ------
211 主線樹是由Linus Torvalds 維護的。你
212 庫中下找到它。它的開發遵循以下
213
214 - 每當一個新版本的內核被發布，
215 維護者可以向Linus提交大段的修
216 星期了。提交大量修改的首選方
217 ，更多的信息可以在 https://git-sc
218 可以的。
219 - 兩個星期以後-rc1版本內核發布
220 新功能的補丁才可能被接受。請
221 可能在-rc1後被接受是因爲這樣
222 沒有造成內核退步的風險。在-rc
223 有的補丁需要同時被發送到相應
224 - 當Linus認爲當前的git源碼樹已經
225 時，一個新的-rc版本就會被發布
226 - 這個過程一直持續下去直到內核
227 6個星期。
228
229 關於內核發布，值得一提的是Andrew
230 「沒有人知道新內核何時會
231 的，而不是根據一個事先制
232
233 子系統特定樹
234 ------------
235
236 各種內核子系統的維護者——以及
237 當前的開發狀態。這樣，其他人就
238 很快的領域，可能會要求開發人員
239 就避免了提交與其他已經進行的工
240
241 這些存儲庫中的大多數都是Git樹，
242 爲Quilt系列。這些子系統存儲庫的
243 https://git.kernel.org/上瀏覽。
244
245 在將一個建議的補丁提交到這樣的
246 在郵件列表上（請參見下面相應的
247 過工具補丁跟蹤的。Patchwork提供了
248 論或修訂，維護人員可以將補丁標
249 在 https://patchwork.kernel.org/
250
251 Linux-next 集成測試樹
252 ---------------------
253
254 在將子系統樹的更新合併到主線樹
255 特殊的測試存儲庫，其中幾乎每天
256
257 https://git.kernel.org/？p=linux/kern
258
259 通過這種方式，Linux-next 對下一個
260 展望。非常歡冒險的測試者運行測
261
262 多個主要版本的穩定版內核樹
263 -----------------------------------
264 由3個數字組成的內核版本號說明此
265 至關重要的修補，這些修補針對安
266
267 這種版本的內核適用於那些期望獲
268 者實驗版的用戶。
269
270 穩定版內核樹版本由「穩定版」小<
271 隔周發布新版本。
272
273 內核源碼中的 :ref:`Documentation/process
274 文件具體描述了可被穩定版內核接
275
276
277 報告bug
278 -------
279
280 bugzilla.kernel.org是Linux內核開發者們
281 戶在這個工具中報告找到的所有bug
282
283 http://test.kernel.org/bugzilla/faq.ht
284
285 內核源碼主目錄中的:ref:`admin-guide/r
286 文件里有一個很好的模板。它指導
287 來幫助內核開發者們找到問題的根
288
289
290 利用bug報告
291 -----------
292
293 練習內核開發技能的最好辦法就是
294 得更加穩定，還可以學會如何解決
295 者感受到你的存在。修改bug是贏得
296 人都喜歡浪費時間去修改別人報告
297
298 要嘗試修改已知的bug，請訪問 http:/
299
300
301 郵件列表
302 --------
303
304 正如上面的文檔所描述，大多數的
305 表。如何訂閱和退訂列表的細節可
306
307 http://vger.kernel.org/vger-lists.html
308
309 網上很多地方都有這個郵件列表的
310 存檔。比如：
311
312 https://lore.kernel.org/lkml/
313
314 在發信之前，我們強烈建議你先在
315 討論過的問題只在郵件列表的存檔
316
317 大多數內核子系統也有自己獨立的
318 MAINTAINERS文件中可以找到不同話題
319
320 很多郵件列表架設在kernel.org伺服器
321
322 http://vger.kernel.org/vger-lists.html
323
324 在使用這些郵件列表時，請記住保
325 表（或任何其它郵件列表）交流的
326
327 http://www.albion.com/netiquette/
328
329 當有很多人回覆你的郵件時，郵件
330 列表中刪除，除非你有足夠的理由
331 一封郵件接收兩次（一封來自發送
332 些奇特的郵件頭來解決這個問題，
333
334 記住保留你所回復內容的上下文和
335 這幾行。將你的評論加在被引用的
336
337 如果你在郵件中附帶補丁，請確認
338 :ref:`Documentation/translations/zh_TW/process
339 文檔中所述）。內核開發者們不希
340 保證他們可以直接評論你的每行代
341 和制表符。一個防範性的測試方法
342 順利地打上收到的補丁。如果測試
343 它正確工作爲止。
344
345 總而言之，請尊重其他的郵件列表
346
347
348 同內核社區合作
349 ----------------
350
351 內核社區的目標就是提供盡善盡美
352 時候，它的技術價值以及其他方面
353
354 - 批評
355 - 評論
356 - 要求修改
357 - 要求證明修改的必要性
358 - 沉默
359
360 要記住，這些是把補丁放進內核的
361 從技術層面評估它們，然後要麼重
362 的。如果你發的郵件沒有得到任何
363 沒在茫茫信海中。
364
365 你不應該做的事情：
366
367 - 期望自己的補丁不受任何質疑就
368 - 翻臉
369 - 忽略別人的評論
370 - 沒有按照別人的要求做任何修改
371
372 在一個努力追尋最好技術方案的社
373 解。你必須要抱著合作的態度，願
374 願意去證明你的想法是有價值的。
375 方案去努力。
376
377 如果你的第一個補丁換來的是一堆
378 不會被接受，也不意味著有人和你
379 送你的補丁。
380
381 內核社區和公司文化的差異
382 ------------------------
383
384 內核社區的工作模式同大多數傳統
385 子，可以幫助你避免某些可能發生
386 用這些話介紹你的修改提案會有好
387
388 - 它同時解決了多個問題
389 - 它刪除了2000行代碼
390 - 這是補丁，它已經解釋了我想
391 - 我在5種不同的體系結構上測試
392 - 這是一系列小補丁用來……
393 - 這個修改提高了普通機器的性
394
395 應該避免如下的說法：
396
397 - 我們在AIX/ptx/Solaris就是這麼做
398 - 我做這行已經20年了，所以…
399 - 爲了我們公司賺錢考慮必須這
400 - 這是我們的企業產品線所需要
401 - 這裡是描述我觀點的1000頁設計
402 - 這是一個5000行的補丁用來……
403 - 我重寫了現在亂七八糟的代碼
404 - 我被規定了最後期限，所以這
405
406 另外一個內核社區與大部分傳統公
407 流。使用電子郵件和IRC聊天工具做
408 將會更少。Linux內核的工作環境更
409 里只是一個郵件地址。國際化也幫
410 的性別。男人有可能叫李麗，女人
411 並表達過看法的女性對在linux上工
412
413 對於一些不習慣使用英語的人來說
414 中要正確地表達想法必需良好地掌
415 下英文寫得是否正確。
416
417
418 拆分修改
419 --------
420
421 Linux內核社區並不喜歡一下接收大
422 拆分成獨立的小段。這幾乎完全和
423 開始的階段就讓大家知道，這樣你
424 樣也會讓社區覺得你是在和他們協
425 無論如何，你不要一次性地向郵件
426 這麼多。
427
428 將補丁拆開的原因如下：
429
430 1) 小的補丁更有可能被接受，因爲
431 一個5行的補丁，可能在維護者看
432 需要數個小時來審查其正確性（
433
434 當出了問題的時候，小的補丁也
435 將會比仔細剖析一個被打上的大
436
437 2）不光發送小的補丁很重要，在提
438 補丁也是很重要的。
439
440 這裡有內核開發者Al Viro打的一個比
441 「想像一個老師正在給學生
442 到正確解法所進行的嘗試和
443 解答。好學生了解這點，絕
444
445 內核開發也是這樣。維護者
446 考過程。他們只希望看到簡
447
448 直接給出一流的解決方案，和社區
449 很難找到一個平衡點。所以最好儘
450 保證修改分成很多小塊，這樣在整
451 分可能會先被接收。
452
453 必須了解這樣做是不可接受的：試
454 復。
455
456
457 證明修改的必要性
458 ----------------
459 除了將補丁拆成小塊，很重要的一
460 你必須證明新功能是有人需要的並
461
462
463 記錄修改
464 --------
465
466 當你發送補丁的時候，需要特別留
467 丁的修改記錄(ChangeLog)，會被一直
468 包括：
469
470 - 爲什麼需要這個修改
471 - 補丁的總體設計
472 - 實現細節
473 - 測試結果
474
475 想了解它具體應該看起來像什麼，
476 「The Perfect Patch」
477 https://www.ozlabs.org/~akpm/stuff/tp
478
479
480 這些事情有時候做起來很難。要在
481 一個持續提高的過程，它需要大量
482 很多人已經做到了，而他們都曾經
483
484
485 感謝
486 ----
487 感謝Paolo Ciarrocchi允許「開發流程」
488 (http://www.kerneltravel.net/newbie/2.6-develo
489 Dunlap和Gerrit Huizenga完善了應該說和
490 Linder, Randy Dunlap, Kay Sievers, Vojtech Pav
491 Kees Cook, Andrew Morton, Andi Kleen, Vadim Lo
492 Bunk, Keri Harris, Frans Pop, David A. Wheeler
493 Kerrisk和Alex Shepard的評審、建議和貢
494 能完成的。
495
496
497
498 英文版維護者： Greg Kroah-Hartman <greg@
499
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.