0001 .. SPDX-License-Identifier: GPL-2.0
0002
0003 .. _tw_stable_api_nonsense:
0004
0005 .. include:: ../disclaimer-zh_TW.rst
0006
0007 :Original: :ref:`Documentation/process/stable-api-nonsense.rst
0008 <stable_api_nonsense>`
0009
0010 譯者::
0011
0012 中文版維護者： 鍾宇 TripleX Chung <xxx.phy@gmail.com>
0013 中文版翻譯者： 鍾宇 TripleX Chung <xxx.phy@gmail.com>
0014 中文版校譯者： 李陽 Li Yang <leoyang.li@nxp.com>
0015 胡皓文 Hu Haowen <src.res@email.cn>
0016
0017 Linux 內核驅動接口
0018 ==================
0019
0020 寫作本文檔的目的，是爲了解釋爲什麼Linux既沒有二進位內核接口，也沒有穩定
0021 的內核接口。這裡所說的內核接口，是指內核里的接口，而不是內核和用戶空間
0022 的接口。內核到用戶空間的接口，是提供給應用程式使用的系統調用，系統調用
0023 在歷史上幾乎沒有過變化，將來也不會有變化。我有一些老應用程式是在0.9版本
0024 或者更早版本的內核上編譯的，在使用2.6版本內核的Linux發布上依然用得很好
0025 。用戶和應用程式作者可以將這個接口看成是穩定的。
0026
0027
0028 執行綱要
0029 --------
0030
0031 你也許以爲自己想要穩定的內核接口，但是你不清楚你要的實際上不是它。你需
0032 要的其實是穩定的驅動程序，而你只有將驅動程序放到公版內核的原始碼樹里，
0033 才有可能達到這個目的。而且這樣做還有很多其它好處，正是因爲這些好處使得
0034 Linux能成爲強壯，穩定，成熟的作業系統，這也是你最開始選擇Linux的原因。
0035
0036
0037 入門
0038 -----
0039
0040 只有那些寫驅動程序的「怪人」才會擔心內核接口的改變，對廣大用戶來說，既
0041 看不到內核接口，也不需要去關心它。
0042
0043 首先，我不打算討論關於任何非GPL許可的內核驅動的法律問題，這些非GPL許可
0044 的驅動程序包括不公開原始碼，隱藏原始碼，二進位或者是用原始碼包裝，或者
0045 是其它任何形式的不能以GPL許可公開原始碼的驅動程序。如果有法律問題，請咨
0046 詢律師，我只是一個程式設計師，所以我只打算探討技術問題（不是小看法律問題，
0047 法律問題很實際，並且需要一直關注）。
0048
0049 既然只談技術問題，我們就有了下面兩個主題：二進位內核接口和穩定的內核源
0050 代碼接口。這兩個問題是互相關聯的，讓我們先解決掉二進位接口的問題。
0051
0052
0053 二進位內核接口
0054 --------------
0055 假如我們有一個穩定的內核原始碼接口，那麼自然而然的，我們就擁有了穩定的
0056 二進位接口，是這樣的嗎？錯。讓我們看看關於Linux內核的幾點事實：
0057
0058 - 取決於所用的C編譯器的版本，不同的內核數據結構里的結構體的對齊方
0059 式會有差別，代碼中不同函數的表現形式也不一樣（函數是不是被inline
0060 編譯取決於編譯器行爲）。不同的函數的表現形式並不重要，但是數據
0061 結構內部的對齊方式很關鍵。
0062
0063 - 取決於內核的配置選項，不同的選項會讓內核的很多東西發生改變：
0064
0065 - 同一個結構體可能包含不同的成員變量
0066 - 有的函數可能根本不會被實現（比如編譯的時候沒有選擇SMP支持
0067 一些鎖函數就會被定義成空函數）。
0068 - 內核使用的內存會以不同的方式對齊，這取決於不同的內核配置選
0069 項。
0070
0071 - Linux可以在很多的不同體系結構的處理器上運行。在某個體系結構上編
0072 譯好的二進位驅動程序，不可能在另外一個體系結構上正確的運行。
0073
0074 對於一個特定的內核，滿足這些條件並不難，使用同一個C編譯器和同樣的內核配
0075 置選項來編譯驅動程序模塊就可以了。這對於給一個特定Linux發布的特定版本提
0076 供驅動程序，是完全可以滿足需求的。但是如果你要給不同發布的不同版本都發
0077 布一個驅動程序，就需要在每個發布上用不同的內核設置參數都編譯一次內核，
0078 這簡直跟噩夢一樣。而且還要注意到，每個Linux發布還提供不同的Linux內核，
0079 這些內核都針對不同的硬體類型進行了優化（有很多種不同的處理器，還有不同
0080 的內核設置選項）。所以每發布一次驅動程序，都需要提供很多不同版本的內核
0081 模塊。
0082
0083 相信我，如果你真的要採取這種發布方式，一定會慢慢瘋掉，我很久以前就有過
0084 深刻的教訓...
0085
0086
0087 穩定的內核原始碼接口
0088 --------------------
0089
0090 如果有人不將他的內核驅動程序，放入公版內核的原始碼樹，而又想讓驅動程序
0091 一直保持在最新的內核中可用，那麼這個話題將會變得沒完沒了。
0092 內核開發是持續而且快節奏的，從來都不會慢下來。內核開發人員在當前接口中
0093 找到bug，或者找到更好的實現方式。一旦發現這些，他們就很快會去修改當前的
0094 接口。修改接口意味著，函數名可能會改變，結構體可能被擴充或者刪減，函數
0095 的參數也可能發生改變。一旦接口被修改，內核中使用這些接口的地方需要同時
0096 修正，這樣才能保證所有的東西繼續工作。
0097
0098 舉一個例子，內核的USB驅動程序接口在USB子系統的整個生命周期中，至少經歷
0099 了三次重寫。這些重寫解決以下問題：
0100
0101 - 把數據流從同步模式改成非同步模式，這個改動減少了一些驅動程序的
0102 複雜度，提高了所有USB驅動程序的吞吐率，這樣幾乎所有的USB設備都
0103 能以最大速率工作了。
0104 - 修改了USB核心代碼中爲USB驅動分配數據包內存的方式，所有的驅動都
0105 需要提供更多的參數給USB核心，以修正了很多已經被記錄在案的死鎖。
0106
0107 這和一些封閉原始碼的作業系統形成鮮明的對比，在那些作業系統上，不得不額
0108 外的維護舊的USB接口。這導致了一個可能性，新的開發者依然會不小心使用舊的
0109 接口，以不恰當的方式編寫代碼，進而影響到作業系統的穩定性。
0110 在上面的例子中，所有的開發者都同意這些重要的改動，在這樣的情況下修改代
0111 價很低。如果Linux保持一個穩定的內核原始碼接口，那麼就得創建一個新的接口
0112 ；舊的，有問題的接口必須一直維護，給Linux USB開發者帶來額外的工作。既然
0113 所有的Linux USB驅動的作者都是利用自己的時間工作，那麼要求他們去做毫無意
0114 義的免費額外工作，是不可能的。
0115 安全問題對Linux來說十分重要。一個安全問題被發現，就會在短時間內得到修
0116 正。在很多情況下，這將導致Linux內核中的一些接口被重寫，以從根本上避免安
0117 全問題。一旦接口被重寫，所有使用這些接口的驅動程序，必須同時得到修正，
0118 以確定安全問題已經得到修復並且不可能在未來還有同樣的安全問題。如果內核
0119 內部接口不允許改變，那麼就不可能修復這樣的安全問題，也不可能確認這樣的
0120 安全問題以後不會發生。
0121 開發者一直在清理內核接口。如果一個接口沒有人在使用了，它就會被刪除。這
0122 樣可以確保內核儘可能的小，而且所有潛在的接口都會得到儘可能完整的測試
0123 （沒有人使用的接口是不可能得到良好的測試的）。
0124
0125
0126 要做什麼
0127 --------
0128
0129 如果你寫了一個Linux內核驅動，但是它還不在Linux原始碼樹里，作爲一個開發
0130 者，你應該怎麼做？爲每個發布的每個版本提供一個二進位驅動，那簡直是一個
0131 噩夢，要跟上永遠處於變化之中的內核接口，也是一件辛苦活。
0132 很簡單，讓你的驅動進入內核原始碼樹（要記得我們在談論的是以GPL許可發行
0133 的驅動，如果你的代碼不符合GPL，那麼祝你好運，你只能自己解決這個問題了，
0134 你這個吸血鬼<把Andrew和Linus對吸血鬼的定義連結到這裡>）。當你的代碼加入
0135 公版內核原始碼樹之後，如果一個內核接口改變，你的驅動會直接被修改接口的
0136 那個人修改。保證你的驅動永遠都可以編譯通過，並且一直工作，你幾乎不需要
0137 做什麼事情。
0138
0139 把驅動放到內核原始碼樹里會有很多的好處：
0140
0141 - 驅動的質量會提升，而維護成本（對原始作者來說）會下降。
0142 - 其他人會給驅動添加新特性。
0143 - 其他人會找到驅動中的bug並修復。
0144 - 其他人會在驅動中找到性能優化的機會。
0145 - 當外部的接口的改變需要修改驅動程序的時候，其他人會修改驅動程序
0146 - 不需要聯繫任何發行商，這個驅動會自動的隨著所有的Linux發布一起發
0147 布。
0148
0149 和別的作業系統相比，Linux爲更多不同的設備提供現成的驅動，而且能在更多不
0150 同體系結構的處理器上支持這些設備。這個經過考驗的開發模式，必然是錯不了
0151 的 :)
0152
0153 感謝
0154 ----
0155 感謝 Randy Dunlap, Andrew Morton, David Brownell, Hanna Linder,
0156 Robert Love, and Nishanth Aravamudan 對於本文檔早期版本的評審和建議。
0157
0158 英文版維護者： Greg Kroah-Hartman <greg@kroah.com>
0159
