3. 早期規劃¶
在考慮一個 Linux 核心開發專案時，人們可能會禁不住誘惑，立即著手編寫程式碼。然而，與任何重要專案一樣，成功的大部分基礎最好在編寫第一行程式碼之前就奠定好。早期規劃和溝通所花費的一些時間可以在後期節省更多時間。
3.1. 明確問題¶
與任何工程專案一樣，成功的核心增強始於對要解決的問題的清晰描述。在某些情況下，這一步很簡單：例如，當需要特定硬體的驅動程式時。但在其他情況下，人們往往會混淆實際問題與建議的解決方案，這可能導致困難。
舉個例子：幾年前，從事 Linux 音訊開發的開發者們尋求一種方法，使應用程式能夠執行，而不會出現由系統過度延遲引起的卡頓或其他偽影。他們找到的解決方案是一個旨在掛接到 Linux 安全模組（LSM）框架的核心模組；該模組可以配置為允許特定應用程式訪問即時排程程式。該模組被實現併發送到 linux-kernel 郵件列表，但立即遇到了問題。
對於音訊開發者來說，這個安全模組足以解決他們的燃眉之急。然而，對於更廣泛的核心社群而言，它被視為濫用 LSM 框架（LSM 的目的並非賦予程序額外的特權），並且對系統穩定性構成風險。他們首選的解決方案是短期內透過 rlimit 機制訪問即時排程，以及長期持續進行延遲降低工作。
然而，音訊社群無法跳出他們已實現的特定解決方案；他們不願接受其他替代方案。由此產生的意見分歧讓這些開發者對整個核心開發過程感到幻滅；其中一人回到音訊郵件列表併發布了這條訊息：
有很多非常優秀的 Linux 核心開發者，但他們往往被一大群傲慢的蠢貨蓋過風頭。試圖向這些人傳達使用者需求簡直是浪費時間。他們太“聰明”了，不屑於傾聽凡夫俗子的意見。
(https://lwn.net/Articles/131776/)。
實際情況並非如此；核心開發者更關心繫統穩定性、長期維護以及找到正確的解決方案，而不是某個特定的模組。這個故事的寓意是，要專注於問題——而不是某個具體的解決方案——並在投入大量程式碼編寫之前，與開發社群進行討論。
因此，在考慮一個核心開發專案時，應該回答以下幾個簡短的問題：
究竟需要解決什麼問題？
哪些使用者受到這個問題的影響？解決方案應該解決哪些用例？
目前核心在解決這個問題上有什麼不足？
只有這樣，才開始考慮可能的解決方案。
3.2. 早期討論¶
在規劃核心開發專案時，在開始實施之前與社群進行討論非常有意義。早期溝通可以透過多種方式節省時間和麻煩：
很可能這個問題已經被核心以你尚未理解的方式解決了。Linux 核心龐大，擁有許多並非顯而易見的功能和能力。並非所有核心功能都得到了人們所希望的良好文件記錄，因此很容易遺漏。本文作者曾見過一份完整的驅動程式釋出，它複製了一個現有驅動程式，而新作者對此一無所知。重複造輪子的程式碼不僅浪費，也不會被主線核心接受。
提議的解決方案中可能存在一些不適合主線合併的元素。最好在編寫程式碼之前發現此類問題。
完全有可能其他開發者也考慮過這個問題；他們可能有更好的解決方案，並可能願意協助建立該解決方案。
多年與核心開發社群打交道的經驗清楚地表明瞭一個教訓：閉門設計和開發的核心程式碼總是存在問題，這些問題只有在程式碼釋出到社群後才會暴露出來。有時這些問題非常嚴重，需要數月甚至數年的努力才能使程式碼達到核心社群的標準。一些例子包括：
Devicescape 網路棧是為單處理器系統設計和實現的。它直到被改造為適用於多處理器系統後才能合併到主線。將鎖定等功能改造到程式碼中是一項艱鉅的任務；因此，該程式碼（現在稱為 mac80211）的合併被推遲了一年多。
Reiser4 檔案系統包含了一些功能，核心核心開發者認為這些功能應該在虛擬檔案系統層實現。它還包含了一些功能，如果實現不當，很容易導致使用者引起的死鎖。這些問題被遲遲發現——以及拒絕解決其中一些問題——導致 Reiser4 一直未能進入主線核心。
AppArmor 安全模組以被認為不安全和不可靠的方式使用了內部虛擬檔案系統資料結構。這一擔憂（以及其他擔憂）使 AppArmor 多年來未能進入主線。
在所有這些案例中，如果能與核心開發者進行一些早期討論，就可以避免大量的痛苦和額外工作。
3.3. 和誰交談？¶
當開發者決定公開他們的計劃時，下一個問題是：我們從何開始？答案是找到正確的郵件列表和正確的維護者。對於郵件列表，最好的方法是在 MAINTAINERS 檔案中查詢一個相關的釋出地點。如果有合適的子系統列表，在那裡釋出通常比在 linux-kernel 上釋出更好；你更有可能接觸到在相關子系統方面有專長的開發者，而且環境可能更具支援性。
找到維護者可能有點困難。同樣，MAINTAINERS 檔案是起點。然而，該檔案往往並非總是最新的，而且並非所有子系統都在其中有所體現。MAINTAINERS 檔案中列出的人，實際上可能並非當前擔任該角色的人。因此，當不確定聯絡誰時，一個有用的技巧是使用 git（特別是“git log”）來檢視感興趣的子系統中有誰是活躍的。檢視誰在編寫補丁，以及誰（如果有的話）在這些補丁上附有 Signed-off-by 行。這些人將最適合協助新的開發專案。
找到合適的維護者有時具有相當大的挑戰性，以至於核心開發者添加了一個指令碼來簡化這個過程：
.../scripts/get_maintainer.pl
當給定“-f”選項時，此指令碼將返回給定檔案或目錄的當前維護者。如果透過命令列傳遞補丁，它將列出應該接收補丁副本的維護者。這是獲取你的補丁需要抄送的人員列表的首選方法（與“-f”選項不同）。有許多選項可以調節 get_maintainer.pl 搜尋維護者的難度；請注意不要使用更激進的選項，因為你最終可能會包含那些對你正在修改的程式碼沒有實際興趣的開發者。
如果所有其他方法都失敗了，與 Andrew Morton 交談是找到特定程式碼維護者的有效方法。
3.4. 何時釋出？¶
如果可能，在早期階段釋出你的計劃只會帶來幫助。描述要解決的問題以及為實現方式所做的任何計劃。你提供的任何資訊都可以幫助開發社群為專案提供有用的意見。
在此階段可能發生的一件令人沮喪的事情並非敵意反應，而是幾乎沒有或根本沒有反應。令人遺憾的事實是：(1) 核心開發者通常很忙，(2) 擁有宏偉計劃但程式碼很少（甚至沒有程式碼前景）的人不在少數，以及 (3) 沒人有義務審查或評論他人提出的想法。除此之外，高層設計常常隱藏著只有當有人真正嘗試實現這些設計時才會暴露出來的問題；因此，核心開發者寧願看到程式碼。
如果徵求意見的帖子幾乎沒有得到評論，不要以為這意味著對專案不感興趣。不幸的是，你也不能假設你的想法沒有問題。在這種情況下，最好的做法是繼續推進，並隨時向社群通報進展。
3.5. 獲得官方認可¶
如果你的工作是在企業環境中完成的——就像大多數 Linux 核心工作一樣——那麼顯然，你必須獲得擁有適當許可權的經理的許可，才能將你公司的計劃或程式碼釋出到公共郵件列表。釋出未經許可在 GPL 相容許可下發布的程式碼可能尤其成問題；公司管理層和法務人員越早同意釋出核心開發專案，所有相關人員的情況就越好。
有些讀者此時可能在想，他們的核心工作旨在支援一個尚未得到官方承認存在的產品。在公共郵件列表上透露僱主的計劃可能不是一個可行的選擇。在這種情況下，值得考慮這種保密是否真的必要；通常沒有真正的必要將開發計劃秘而不宣。
話雖如此，也有一些情況是公司在開發過程早期合法地不能披露其計劃。擁有經驗豐富的核心開發者的公司可能會選擇以開放式迴圈的方式進行，假設他們將來能夠避免嚴重的整合問題。對於沒有這種內部專業知識的公司，最好的選擇通常是聘請外部開發者在保密協議下審查計劃。Linux 基金會運營一個 NDA 專案，旨在幫助處理此類情況；更多資訊可在以下網址找到：
這種審查通常足以避免後期出現嚴重問題，而無需公開披露專案。