維基百科

Linux內核

類Unix操作系統內核
提示：此條目頁的主題不是GNU/Linux或Linux-libre。

Linux內核（英語：Linux kernel）是一種開源的類Unix作業系統整塊性核心。整個Linux作業系統家族基於該內核部署在傳統電腦平台（如個人電腦和伺服器，以Linux發行版的形式[8]）和各種嵌入式平台，如路由器、無線存取點、專用小交換機、機頂盒、FTA接收器（英語：FTA receiver）、智能電視、數碼影片錄像機、網絡附加儲存（NAS）等。工作於平板電腦、智能電話及智能手錶的Android作業系統同樣通過Linux內核提供的服務完成自身功能。儘管於桌面電腦的佔用率較低，基於Linux的作業系統統治了幾乎從流動裝置到主機的其他全部領域。截至2017年11月，世界前500台最強的超級電腦全部使用Linux。[9]

Linux
Linux官方的吉祥物，一隻叫Tux的企鵝
Linux內核3.0.0啟動畫面
開發者林納斯·托瓦茲（Linus Torvalds）和幾千名合作者
程式語言C語言、Rust、匯編語言
作業系統家族類Unix系統
首次釋出0.01（1991年9月17日，​33年前​（1991-09-17））
目前版本
  • 6.12-rc5（2024年10月27日；最終測試版本）[1]
  • 6.11.6（2024年11月1日；穩定版本）[2]
編輯維基數據連結
最新預覽Kernel: 6.2-rc5[3]（2023年1月21日，​21個月前​（2023-01-21））[±]
支援的語言多語言
內核類別整塊性核心
特許條款GPL（僅）第二版[4][5]，
各類封閉韌體的特許條款[6][7]
官方網站www.kernel.org 編輯維基數據連結
倉庫
編輯維基數據連結

Linux內核最早是於1991年由芬蘭黑客林納斯·托瓦茲為自己的個人電腦開發的，他當時在Usenet新聞組comp.os.minix登載貼文[10]，這份著名的貼文標誌着Linux內核計劃的正式開始。如今，該計劃已經拓展到支援大量的電腦體系架構，遠超其他作業系統和內核。它迅速吸引了一批開發者和用戶，利用它作為其他自由軟件專案的內核，如著名的 GNU 作業系統。[11]而今天，Linux 內核已接受了超過1200家公司的近12000名程式設計師的貢獻，其中包括一些知名的軟硬件發行商。[12][13]

從技術上說，Linux 只是一個符合POSIX 標準的內核。它提供了一套應用程式介面（API），通過介面用戶程式能與內核及硬件互動。僅僅一個內核並不是一套完整的作業系統。有一套基於 Linux 內核的完整作業系統叫作Linux 作業系統，或是GNU/Linux（在該系統中包含了很多GNU 計劃的系統組件）。

Linux 內核是在GNU通用公眾特許條款第2版之下釋出的[5]（加上一些非自由韌體、blob與各種非自由特許條款[14]），是一個開源專案協同運作的突出例子。它的版本支援根據版本最長可達6年，貢獻者遍佈世界各地，日常開發相關的討論在Linux 內核郵寄清單（英語：Linux kernel mailing list）上。

歷史

編輯
主條目：Linux歷史
 
林納斯·托瓦茲

1991年，林納斯·托瓦茲，一名21歲的就讀於芬蘭赫爾辛基大學的電腦科學專業學生，基於一些簡單的想法，打算編寫一個作業系統內核。他通過英特爾80386匯編語言的工作切換器和一個終端驅動程式開始工作。8月25號，他在comp.os.minix新聞組里發了一封貼文：[15]

我在做個（自由的）作業系統（就是個興趣愛好，我不會搞得像GNU那麼大那麼專業），打算讓它工作在386 AT平台上。它從四月就開始醞釀了，馬上就快好了。我想要那些喜歡或不喜歡minix的人的意見，因為我的系統和它有點類似（同樣的檔案系統的物理佈局——由於實際原因——還有些其他的東西）。

我現在已經移植了bash(1.08)和gcc(1.40)， 而且看起來奏效了。這意味着我會在幾個月內得到一些實用的東西。「……」是的——它沒有任何minix代碼，並且它有一個多線程的fs。它不可移植（使用386工作切換等），而且它可能永遠不會支援除AT硬碟之外的其他東西，因為我只有這些:-(。

「……」它基本上是用C語言寫的，但是大多數人可能不會把我寫的東西叫做C語言。它使用我能找到的386的每個可以想像的特性，因為它也是一個教我關於386的功能的專案。我前面提到過，它使用主記憶體管理單元來進行分頁（還沒實現到對硬碟的功能）和分段。這個分段功能使得它真正的依賴於386（每個任務都有64Mb的代碼和數據段——4Gb中最多64個任務。如果有人需要超過每個任務64Mb的限制，那將是個麻煩事）。「……」我的一些C語言檔案（特別是mm.c）幾乎用了和C一樣多的組譯。「……」不像minix，我也碰巧喜歡中斷，所以中斷將在不試圖隱藏背後的原因的情形下被處理。

之後，許多人為這個專案貢獻了代碼。在早期，MINIX社區向 Linux 內核貢獻了代碼和想法。當時，GNU 專案已經建立了許多自由作業系統所需的組件，但是它自己的內核 GNU Hurd 尚不完整且無法使用；而BSD作業系統還沒有擺脫合法的阻礙。因此，儘管早期版本的 Linux 功能有限，但它迅速獲得了開發人員和用戶。

到1991年9月，Linux內核版本 0.01 在芬蘭大學和研究網絡（FUNET）的FTP伺服器（ftp.funet.fi）上釋出。它有10,239行代碼。在1991年10月，0.02版本的內核釋出了。[16]

1991年12月，0.11版本的內核釋出。由於它可以由執行相同內核版本的電腦編譯，因此該版本是第一個自寄存（英語：Self-hosting (compilers)）的 Linux 內核。當托瓦茲於1992年2月釋出0.12版本時，他採用了 GNU 通用公眾特許條款（GPL），而不是以前的自行起草的特許條款，原先的特許條款不允許商業再分發。[17]

1992年1月19日，第一篇文章提交給新的新聞組alt.os.linux出現。[18]1992年3月31日，該新聞組更名為 comp.os.linux。[19]

X Window 系統隨後被移植到Linux上，所以在1992年3月，Linux 0.95 是第一個能夠執行X的版本。從0.1x到0.9x的版本號大幅跨越是因為期望沒有大的缺失部分的版本1.0的即將出現。然而，這被證明是錯誤的。從1993年到1994年初，出現了0.99版本的15個開發版本。

1994年3月14日，Linux內核1.0.0釋出，共176,250行代碼。隨後的1995年3月，有310,950行代碼的 Linux 內核1.2.0釋出。

在1996年6月9日釋出的 Linux內核2.0版本之後，以2.0為大版本的主要更新有如下這些：

  • 1999年1月25日 - 釋出Linux內核2.2.0（1,800,847行代碼）
  • 1999年12月18日 - 針對2.2.13的 IBM 大型電腦修補程式釋出，允許 Linux 內核用於企業級機器
  • 2001年1月4日 - 釋出 Linux 內核2.4.0（3,377,902行代碼）
  • 2003年12月17日 - 釋出 Linux 內核2.6.0（5,929,913行代碼）

從2004年開始，釋出過程發生了變化，新的內核每隔2-3個月定期釋出，編號為2.6.0、2.6.1，直到2.6.39。

2011年7月21日，Torvalds宣佈釋出Linux內核3.0：「2.6.<大版本> 的日子過去了」。[20]與Linux 2.6.39相比，大的技術變化同版本躍升沒有關係；[21]它標誌着內核的20周年紀念。[22]基於時間的釋出過程保持不變。

2013年6月釋出的Linux內核版本3.10包含15,803,499行代碼[23]，而2015年6月釋出的4.1版本已發展到超過1950萬行代碼，由近14000名程式設計師貢獻。[24]

塔能鮑姆-林納斯辯論

編輯
主條目：塔能鮑姆-林納斯辯論

Linux不是微內核架構的事實曾經引起了林納斯·托瓦茲與安德魯·史超域·塔能鮑姆之間一場著名的爭論。1992年在Usenet討論群組comp.os.minix[25]開始了一場網絡論戰，討論的主題在於作業系統架構的選擇。稍後一些著名的黑客也加入討論，如大衛·米勒、曹子德。這場辯論影響了Linux內核的設計走向。塔能鮑姆認為Linux內核採用的整塊性核心已經過時了，應該採取比較先進的微內核架構，引起了林納斯的反擊。

在2006年5月9日，這個主題被重新審視[26]，並且在2006年5月12日塔能鮑姆寫了一份立場聲明。[27]

架構

編輯
參見：vmlinux
 
Linux內核地圖

Linux是一個單體內核，支援真正的搶佔式多工處理（於用戶態，和版本2.6系列之後的內核態[28][29]）、虛擬記憶體、共用庫、請求分頁（英語：Demand paging）、共用寫時複製可執行體（通過內核同頁合併（英語：Kernel same-page merging））、主記憶體管理、Internet協定族和線程等功能。

裝置驅動程式和內核擴充執行於內核空間（在很多CPU架構中是ring 0），可以完全訪問硬件，但也有執行於用戶空間的一些例外，例如基於FUSE/CUSE的檔案系統，和部分UIO[30][31]。多數人與Linux一起使用的圖形系統不執行在內核中。與標準單體內核不同，Linux的裝置驅動程式可以輕易的組態為內核模組，並在系統執行期間可直接裝載或解除安裝。也不同於標準單體內核，裝置驅動程式可以在特定條件下被搶佔；增加這個特徵用於正確處理硬件中斷並更好的支援對稱多處理[29]。出於自願選擇，Linux內核沒有二進制內核介面[32]。

硬件也被整合入檔案層級中。用戶應用到裝置驅動的介面是在/dev或/sys目錄下的入口檔案[33]。行程資訊也通過/proc目錄對映到檔案系統[33]。

Linux內的各種層，還顯示了在用戶空間和內核空間之間的分離。
用戶模態 用戶應用 例如：Bash，LibreOffice，GIMP，Blender，0 A.D.，Mozilla Firefox等
低層系統構件 系統守護行程：
systemd，runit，logind，networkd，PulseAudio等 		窗口系統：
X11，Wayland，SurfaceFlinger(Android) 		其他庫：
GTK+, Qt, EFL, SDL, SFML, FLTK, GNUstep等 		圖形：
Mesa，AMD Catalyst等
C標準庫 open()，exec()，sbrk()，socket()，fopen()，calloc()，... (直到2000個次常式)
glibc目標為POSIX/SUS相容，musl和uClibc目標為嵌入式系統，bionic為Android而寫等
內核模態 Linux內核 stat, splice, dup, read, open, ioctl, write, mmap, close, exit等（大約380個系統呼叫）
Linux內核系統呼叫介面（SCI，目標為POSIX/SUS相容）
行程排程子系統 IPC子系統 主記憶體管理子系統 虛擬檔案子系統 網絡子系統
其他構件：ALSA，DRI，evdev，LVM，device mapper，Linux Network Scheduler，Netfilter
Linux安全模組：SELinux，TOMOYO，AppArmor, Smack
硬件（CPU，主記憶體，數據儲存裝置等。）

程式語言

編輯

Linux是用C語言中的GCC版（這種C語言有對標準C進行擴展）寫的，還有幾個用匯編語言（用的是GCC的"AT&T風格"）寫的目標架構短段。因為要支援擴展的C語言，GCC在很長的時間里是唯一一個能正確編譯Linux的編譯器。有許多其他的語言用在一些方面上，主要集中在內核構建過程中（這裏指從原始碼創建可啟動鏡像）。包括Perl、Python和多種手稿語言。有一些驅動可能是用C++、Fortran或其他語言寫的，但是這樣是強烈不建議的。

編譯器相容性

編輯

GCC是Linux內核原始碼的預設編譯器。在2004年，Intel主張通過修改內核，以便Intel C++編譯器能正確編譯內核。[34]在2009年，有通過修改內核2.6.22版而成功編譯的報告（並帶來平均8-9%效能增長）。[35][36]

自從2010年，已經開始進行使用Clang建造Linux內核的努力，Clang是一個可作為替代的C語言編譯器[37]；截止2014年4月12日，官方內核幾乎可以完全用Clang編譯[38][39]。致力於這個目標的計劃叫做「LLVMLinux」，得名於Clang所基於的LLVM編譯器下部構造[40]。LLVMLinux不意圖複製Linux內核或LLVM，因此它是由最終提交給上游計劃的修補程式構成的一個元計劃。使Linux內核可以用Clang編譯最大的好處是比GCC有更快的編譯速度，內核開發者可以得益於由此而來的更快的工作流程[41]。

介面

編輯
主條目：Linux內核介面（英語：Linux kernel interfaces）
 
區分四種介面：兩種內核內部，兩種在內核和用戶空間之間。

符合標準是Linux內核內部的普遍策略。另一個規則是Linux內核主線不接受只由專有用戶空間軟件使用的內核模組。

內核至用戶空間API

編輯
主條目：POSIX和單一UNIX規範
 
Linux API組成自Linux內核的系統呼叫介面、GNU C函式庫、libcgroup[42]、libdrm、libalsa和libevdev[43]。

原始碼可移植性確保符合標準的C程式可以在符合同樣標準的任何系統上編譯和執行。Linux內核開發、GNU C函式庫和相關的實用工具致力於追隨POSIX和單一UNIX規範。Linux內核API（英語：Linux kernel interfaces）是內核的系統呼叫介面。

內核至用戶空間ABI

編輯
主條目：Linux標準規範

二進制可移植性將保證任何程式在符合標準的給定硬件平台上一旦編譯通過，可以在符合同樣標準的任何其他硬件平台上以編譯後的形式執行。二進制可移植性是在基於Linux內核的作業系統上建造獨立軟件供應商（ISV）應用有商業可行性的本質要求。現有唯一的二進制相容標準是Linux標準規範（LSB）。

內核內API

編輯
 
圖形的數據和指令被傳送至GPU來處理。彩現呈現的結果被儲存在幀緩衝區，其中的內容由影片顯示控制器掃描並行送至螢幕。

在不同子系統間使用了數個內核內部API。其中一些是跨越多個發行版保持穩定的，另一些則不然。對於內核內API不作擔保。維護者和貢獻者可以在任何時候增加或變更它們[44]。

內核內API的例子包括針對下列類別裝置驅動程式的軟件框架/API：

內核內ABI

編輯

Linux內核開發者選擇不維護穩定的內核內ABI[46]。

技術特性

編輯

搶佔式排程系統

編輯
 
I/O排程器在Linux內核儲存棧各層內的位置。[47]

Linux內核提供在特定條件下的搶先式排程。直到內核版本2.4，只有用戶行程是搶先式的，就是說除了時間片用盡，在用戶模式下執行的當前行程，如果有更高態優先級的行程進入TASK_RUNNING狀態，它就會被中斷[48]。自從2.6系列Linux內核，增加了中斷執行內核代碼的任務的能力，但不是對於內核代碼的所有段落[49]。

Linux內核含有不同的排程器類[50]。內核預設使用的排程機制叫做完全公平排程器，它介入於內核版本2.6.23[51]。這個預設排程器類在內部也叫做SCHED_OTHER，而內核還含有兩個遵循POSIX的即時排程類[52]，分別叫做SCHED_FIFO（即時先進先出）和SCHED_RR（即時輪串流），二者都優先於預設類[50]。

通過使用即時Linux內核修補程式PREEMPT_RT，可以支援對關鍵段落、中斷處理器和「中斷禁用」代碼序列的完全搶先[53]。 即時Linux內核修補程式部分地整合入主線內核已經帶給它一些功能[54]。搶先機制改善延遲、增進響應性，並使得Linux更加適合桌面和即時應用。老版本內核有所謂的巨鎖（英語：Giant lock），用於鎖定粒度為整個內核的同步，它最終由Arnd Bergmann在2011年移除了[55]。

還有叫做SCHED_DEADLINE（英語：SCHED_DEADLINE）的排程策略，實現了最近截止期限最先（英語：earliest deadline first scheduling）（EDF）演算法，它增加於2014年3月30日發行的內核版本3.14[56][57]。

可移植性

編輯
 
DragonBox Pyra（英語：DragonBox Pyra）上執行Linux

儘管林納斯·托瓦茲的初衷不是使Linux成為一個可移植的作業系統，今天的Linux卻是全球被最廣泛移植的作業系統內核。從流動電話到超級電腦，甚至於有人成功的將Linux內核在索尼出品的遊戲機PS2及PS3和微軟出品的遊戲機Xbox上使用。Linux也是IBM超級電腦Blue Gene的作業系統。直至2011年11月，全球前五百大超級電腦（TOP500）有高達91.4%的比例採用Linux為它們的作業系統[58]。一些為手機開發的作業系統，使用Linux內核的修改後的版本，其中包括谷歌Android、Firefox OS、HP WebOS和諾基亞Maemo。[59][60][61]

內核錯誤和oops

編輯
 
內核錯誤（Kernel panic）
主條目：Kernel panic和Linux內核oops

在Linux中，內核錯誤（Kernel panic）是指作業系統在監測到內核系統內部無法恢復的錯誤，相對於在用戶空間代碼類似的錯誤。作業系統試圖讀寫無效或不允許的主記憶體地址是導致內核錯誤的一個常見原因。內核錯誤也有可能在遇到硬件錯誤或作業系統BUG時發生。在許多情況中，作業系統可以在主記憶體訪問違例發生時繼續執行。然而，系統處於不穩定狀態時，作業系統通常會停止工作以避免造成破壞安全和數據損壞的風險，並提供錯誤的診斷資訊。

在Linux上，oops即Linux內核的行為不正確，並產生了一份相關的錯誤紀錄檔。許多類型的oops會導致內核錯誤，即令系統立即停止工作，但部分oops也允許繼續操作，作為與穩定性的妥協。這個概念只代表一個簡單的錯誤。當內核檢測到問題時，它會列印一個oops資訊然後殺死全部相關行程。oops資訊可以幫助Linux內核工程師除錯，檢測oops出現的條件，並修復導致oops的程式錯誤。

安全

編輯

電腦安全是一個非常公眾化的主題，關係到Linux內核，因為大量在內核中的錯誤可能成為潛在的安全漏洞，是否允許提升權限漏洞或阻斷服務攻擊源漏洞。[62]在過去的幾年中，許多這樣的缺陷被發現，並在Linux內核中被修補好。新的安全功能被繼續實現，以解決在Linux內核中的電腦不安全問題。[63][64]

批評者指責內核開發人員，稱他們掩蓋（至少並未公佈）安全漏洞。2008年，作為回應，Torvalds稱：「個人認為，安全漏洞只是『正常的漏洞』。這些漏洞我並不去掩蓋，不過我不認為應當把它們特殊化，更不認為應該追蹤並公示它們……我不理會整個安全團隊，原因之一就是，我認為這些漏洞不僅美化還鼓勵了錯誤的行為。這令安全人員成了『英雄』，就猶如不修補正常漏洞的人就不值一提似的。而事實上，所有無聊的正常漏洞極為重要，僅僅因為它們實在太多了。我不認為該美化和關心那些嚴重的安全漏洞——它們並不及那些由死鎖造成的隨機嚴重崩潰來得更特殊。」[65][66]

如2012年五月，SYSRET指令被發現在AMD和英特爾處理器間在實現方面有差異，這個差異在Windows、FreeBSD、XenServer和Solaris這些主流作業系統會導致漏洞。2012年六月，Linux內核中該問題已被修復。[67]

2021年，來自明尼蘇達大學的研究人員，曾藉由貢獻修補程式至Linux內核的名義，利用修補程式匯入Bug和漏洞，以觀察Linux內核社群的反應，再度故技重施時被發現，之後維護人員封鎖了所有來自該大學的貢獻，與移除過去該大學曾經貢獻的程式碼。[68]

開發

編輯

開發者社區

編輯

截止2007年，內核開發已經從20位最活躍開發者寫80%的代碼轉變為頂端30人寫30%的代碼，而頂端開發者花費更多的時間稽核變更。[69] 開發者還可以按從屬關係來歸類；在2007年，頂端類屬是「不知名」而頂端公司是Red Hat，它佔有12%的貢獻，而知名業餘愛好者佔3.9%。[69] 在2007年中所做內核變更已經由超過1900位開發者提交。一般假定Linux內核開發者社區由5000或6000名成員組成。

Linux基金會發表的2016年Linux內核開發報告的更新表明，從版本3.18（2014年12月）至4.7（2016年7月）期間：平均每次發行有來自200-250個公司的大約1500位開發者作出貢獻。頂端30位開發者貢獻了稍大於16%的代碼。在公司中，頂端貢獻者是Intel（12.9%）和Red Hat（8.0%），第三和第四位為「none」（7.7%）和「unknown」（6.8%）類屬。

開發過程與模式

編輯

一個想要對 Linux 內核進行修改的開發者一般就從對那個修改的開發和測試開始着手。接下來的過程取決於變化的重要程度，及修改該變更的子系統數量是由單個還是多個修補程式組成。如果僅僅是修改了由單個維護人員維護的單個子系統，那麼這些修改的修補程式代碼就直接通過Cc中某個郵寄清單傳送給相關的維護人員。郵寄清單的閱讀者和子系統的維護人員將檢查修補程式代碼並提供反饋。一旦審查過程完成，維護者接受他內核代碼樹中的修補程式。如果這些更改被認為是夠重要的錯誤修復，那麼包含這些修補程式的拉取請求（pull request）將在幾天內傳送給Linus。否則，將在下一個合併窗口時向Linus傳送拉取請求。合併窗口通常會持續兩周，並在之前的內核版本釋出後立即啟動[70]。

Linus Torvalds擁有對Linux內核能夠接受哪些更改和誰可以成為維護者的最終決定權。內核維護者在他們自願放棄之前將維持他們的角色。目前，沒有任何已知的內核維護者被要求退出。此外，還沒有一個內核維護者因與其他維護者的互動風格的因素而受到Linus批評的例子。這為維護者提供了寬鬆的社區空間。雖然內核開發社區的文化多年來有所改善，但曾有一段時間它的聲譽很糟糕[71][72]。認為自己遭受了不公正對待的開發者可以向Linux基金會的技術專家委員會報告[73]。儘管如此，一些社區成員仍然不認同現在的討論氛圍[74]。

同 Linux 發行版的關係

編輯

大多數Linux用戶執行一個由他們 Linux 發行版提供的內核。一些發行版搭載的是 Linux 的通用內核（也就是 「vanilla」或「stable」）版本。不過，一些Linux內核發行商（如Red Hat和SUSE）會維護他們自己的內核分支。這些發行商分支的內核版本通常相對於穩定版本（vanilla）而言更新的速度更慢一些，但是同樣會包括所有相關的穩定版本分支的修補程式。此外，他們同時也會增添一些新特性和對新硬件的支援，而這些支援是這些發行商分支基於的穩定分支所不包括的。

主線Linux

編輯

包含Linux內核的Linus Torvalds的Git樹被稱為主線Linux。每個穩定的內核釋出都源自主線樹[75]，並經常在kernel.org上釋出。主線Linux只對執行Linux的眾多裝置中的一小部分裝置提供堅實的支援。非主線支援由獨立專案（如Yocto或Linaro）提供，但在許多情況下需要裝置供應商的內核。[76]使用供應商內核可能需要一個板級支援包。

在主線Linux之外維護一個內核樹已被證明是困難的。[77]

主線化（Mainlining）是指將對裝置的支援添加到主線內核中的努力[78]，而以前只有在分支中支援或根本沒有支援。這通常包括添加驅動程式或裝置樹（英語：Devicetree）檔案。完成後，該功能或安全修復被視為mainlined。[79]

重新開發的估價

編輯
 
重新開發Linux內核的估價

按照傳統商業軟件開發的方式，重新開發Linux 2.6.0內核的估計代價將是6.12億美元（4.67億歐元、3.94億英鎊），以2004年的COCOMO人月估計模型.[80]在2006年，歐盟資助的一項研究表明，重新開發Linux 2.6.8以後的內核，代價是8.82億歐元（11.4億美元、7.44億英鎊）[81]。

截至2011年1月4日，使用當前的代碼行（LOC）和大衛·惠勒的計算工資數，這將花費約30億美元（約22億歐元），才能夠重新開發Linux的內核。[82]

版本命名

編輯

Linux內核有三個不同的命名方案。早期版本：第一個版本的內核是0.01，其次是0.02,0.03,0.10,0.11,0.12（第一GPL版本),0.95,0.96,0.97,0.98,0.99及1.0。[83]，從0.95版有許多的修補程式釋出於主要版本版本之間。

舊計劃（1.0和2.6版之間)，版本的格式為A.B.C，其中A,B,C代表：A大幅度轉變的內核，這是很少發生變化，只有當發生重大變化的代碼和內核發生才會發生，在歷史上曾改變兩次的內核：1994年的1.0及1996年的2.0； B是指一些重大修改的內核，內核使用了傳統的奇數次要版本號碼的軟件號碼系統（用偶數的次要版本號碼來表示穩定版本）；C是指輕微修訂的內核，這個數字當有安全修補程式，bug修復，新的功能或驅動程式，內核便會有變化。自2.6.0（2003年12月）釋出後，人們認識到，更短的釋出周期將是有益的。自那時起，版本的格式為A.B.C.D，其中A,B,C,D代表：A和B是無關緊要的，C是內核的版本，D是安全修補程式。

自3.0（2011年7月）釋出後，版本的格式為3.A.B，其中A,B代表：A是內核的版本，B是安全修補程式。而4.0（2015年4月）釋出後，則延續3.A.B的命名格式，只是將主版號變更為4。

法律層面

編輯

特許條款

編輯

原先托瓦茲將 Linux 置於一個禁止任何商業行為的條例之下[84]，但0.12版本之後改用 GNU 通用公眾特許條款第二版。[17] 該協定允許任何人對軟件進行修改或發行，包括商業行為，只要其遵守該協定，所有基於Linux的軟件也必須以該協定的形式發表，並提供原始碼。

托瓦茲曾經公開聲稱將Linux置於GNU通用公眾特許條款之下是他一生中所做的「最好的決定」。[84]

GPL第三版

編輯

Linux 內核明確地僅發表在 GNU 通用公眾特許條款（GPL）第二版下，[5]而不向被特許方提供選擇「任何更高版本」的選項（這是常見的 GPL 擴充）。關於如何輕鬆地改變特許條款以使用後來的 GPL 版本（包括第3版）以及這種更改是否合乎需要，存在着相當多的爭論。[85] 托瓦茲本人在版本2.4.0的釋出中明確指出，他自己的代碼僅在版本2下釋出。[86]然而，GPL的條款規定，如果沒有指定版本，那麼可以使用任何版本；[87]並且亞倫·考克斯指出，很少有其他 Linux 貢獻者指定了特定版本的 GPL。[88]

2006年9月，對29位關鍵內核程式設計師的調查顯示其中的28位更傾向於使用 GPL 第二版（GPLv2）而非當時的 GPL 第三版（GPLv3）草案。 托瓦茲評論說：「我認為一些外界人士......相信我才是那個古怪不合群的人，因為我這麼大張旗鼓地不做 GPLv3 的忠實粉絲。」[89]這些高水平的內核開發者就大眾媒體對 GPLv3 的反對發表了評論，其中包括林納斯·托瓦茲本人、葛雷格·克羅哈曼和安德魯·莫頓。[90]他們提到有關DRM/TiVo化（日語：TiVo化）、專利及「附加限制」的條款，並警告GPLv3對「開源宇宙」的巴爾幹化。[90][91]決定不採用 GPLv3 作為 Linux 內核特許條款的托瓦茲在幾年後重申了他的批評。[92]

韌體爭議

編輯

特許條款爭議的一個重點是Linux使用韌體二進位包以支援某些硬件裝置。李察·馬菲·斯托曼認為這些東西讓Linux某部份成為非自由軟件，甚至以此散佈Linux更會破壞GPL，因為GPL需要完全可獲取的原始碼[93]。

林納斯·托瓦茲及Linux社群中的領導者，支援較寬鬆的特許條款，不支援李察·馬菲·斯托曼的立場。社群中的Linux-libre提供完整的自由軟件韌體。

載入式內核模組特許條款

編輯

另一個爭論點，就是載入式內核模組是否算是知識產權下的衍生創作，意即LKM是否也受GPL約束？托瓦茲本人相信LKM僅用一部分「公開」的內核介面，因此不算衍生創作，因此允許一些僅有二進位包裹的驅動程式或不以GPL宣告的驅動程式用於內核。但也不是每個人都如此同意，且托瓦茲也同意很多LKM的確是純粹的衍生創作，也寫下「基本上，內核模組是衍生創作」這樣的句子。另一方面托瓦茲也說過：

有時候一些驅動程式原先並非為Linux設計，而是為其他作業系統而作（意即並非為Linux作的衍生創作），這是個灰色地帶……這「的確」是個灰色地帶，而我個人相信一些模組可視為非Linux衍生創作，是針對Linux設計，也因此不會遵守Linux訂下的行為準則。[94]

特別像繪圖卡驅動程式就有非常大的爭議，也許到最後得由立法機關給個答案。

SCO爭議

編輯
更多資訊：SCO-Linux爭議

在2003年3月，SCO Group對IBM提告，聲稱IBM將一些在SCO知識產權特許條款保護下的Unix原始碼植入Linux中，破壞了SCO給予IBM的原始碼使用許可權。另外SCO也發出一大堆存證函給許多公司，警告他們在沒有SCO許可權的情況下使用了Linux，此舉可能導致侵犯知識產權，並且以起訴為手段對個別用戶施壓。SCO也同時對Novell、戴姆勒克萊斯勒（DaimlerChrysler，在2004年7月被部份駁回）以及AutoZone提出告訴，且被Red Hat與其他反對SCO論點的公司反告。2007年8月24日，聯邦法院審理SCO對Novell案（SCO v. Novell），法院認定Novell才是Unix商標的合法擁有者，而不是SCO。2010年3月20日，美國聯邦第十巡迴上訴法院宣判，Novell才是UNIX與UnixWare商標的合法擁有者。此項判決宣佈後，已進入破產保護程式的SCO公司，決定停止繼續提出訴訟。

參見

編輯

參考文獻

編輯
  1. ^ 林納斯·托瓦茲. Linux 6.12-rc5. 2024年10月27日 [2024年10月28日]. 
  2. ^ 葛雷格·克羅哈曼. Linux 6.11.6. 2024年11月1日 [2024年11月1日]. 
  3. ^ Torvalds, Linus. Linux 6.2-rc5. LKML (郵寄清單). 2023-01-21 [2023-01-21]. 
  4. ^ InfoWorld. Linux creator Torvalds still no fan of GPLv3. [2008-10-11]. （原始內容存檔於2013-06-23）. 
  5. ^ 5.0 5.1 5.2 COPYING. [2021-02-07]. （原始內容存檔於2012-12-21）. 
  6. ^ Stallman, Richard. Linux, GNU, and freedom. Free Software Foundation. 2002 [2007-02-21]. （原始內容存檔於2013-06-23）. 
  7. ^ linux/kernel/git/stable/linux-stable.git/blob - firmware/WHENCE. git.kernel.org. 2002-10-16 [2012-08-21]. （原始內容存檔於2013-01-13）. 
  8. ^ README - kernel/git/torvalds/linux.git - Linux kernel source tree. git.kernel.org. [2018-02-18]. （原始內容存檔於2020-08-10） （英語）. 
  9. ^ TOP500 Supercomputer Sites. www.top500.org. [2018-02-18]. （原始內容存檔於2012-11-19） （英語）. 
  10. ^ What would you like to see most in minix?. Linus Benedict Torvalds. 1991-08-26 [2010-12-21]. （原始內容存檔於2019-10-18）. 
  11. ^ Free as in Freedom: Chapter 9. www.oreilly.com. [2018-02-18]. （原始內容存檔於2020-12-10）. 
  12. ^ The Linux Foundation Releases Linux Development Report. 2016-07-19 [2018-02-18]. （原始內容存檔於2016-07-19）. 
  13. ^ Greg Kroah-Hartman. Linux Kernel Development: How Fast it is Going, Who is Doing It, What They are Doing, and Who is Sponsoring It (PDF). [2018-02-19]. （原始內容存檔於2019-09-12）. 
  14. ^ git.kernel.org - linux/kernel/git/stable/linux-stable.git/blob - firm…. archive.is. 2013-01-13 [2018-02-18]. （原始內容存檔於2013-01-13）. 
  15. ^ Torvalds, Linus Benedict. What would you like to see most in minix?. Newsgroup: comp.os.minix. 1991-08-26 [2018-02-18]. Usenet: 1991Aug25.205708.9541@klaava.Helsinki.FI. （原始內容存檔於2013-05-09）. 
  16. ^ Torvalds, Linus Benedict. Free minix-like kernel sources for 386-AT. Newsgroup: comp.os.minix. 1991-10-05 [2018-03-28]. Usenet: 1991Oct5.054106.4647@klaava.Helsinki.FI. （原始內容存檔於2013-04-25）. 
  17. ^ 17.0 17.1 Torvalds, Linus. Release Notes for Linux v0.12. The Linux Kernel Archives. [2007-02-21]. （原始內容存檔於2007-08-19）. 
  18. ^ Summers, David W. Troubles with Partitions. Newsgroup: alt.os.linux. 1992-01-19 [2007-01-07]. Usenet: 1992Jan19.085628.18752@cseg01.uark.edu. （原始內容存檔於2013-06-02）. 
  19. ^ Clegg, Alan B. It's here!. Newsgroup: comp.os.linux. 1992-03-31 [2007-01-07]. Usenet: 1992Mar31.131811.19832@rock.concert.net. （原始內容存檔於2013-06-02）. 
  20. ^ Torvalds, Linus. Linux 3.0 release. Linux kernel mailing list. 2011-07-21 [2013-05-16]. （原始內容存檔於2019-10-18）. 
  21. ^ Leemhuis, Thorsten. Linux Kernel Data. The H. Heinz Heise. 2011-05-19 [2011-07-22]. （原始內容存檔於2020-08-08）. 
  22. ^ Hachman, Mark. Linux 3.0 Released; Linus Torvalds Explains Why You Shouldn't Care. PC Magazine. Ziff Davis. 2011-07-22 [2014-11-11]. （原始內容存檔於2019-02-17）. 
  23. ^ Leemhuis, Thorsten. What's new in Linux 3.10. The H. Heinz Heise. 2013-07-01 [2013-07-15]. （原始內容存檔於2014-02-20）. 
  24. ^ Linux Kernel At 19.5 Million Lines Of Code, Continues Rising. Phoronix. 2014-06-23 [2015-06-23]. （原始內容存檔於2020-11-23）. 
  25. ^ A. S. Tanenbaum. LINUX is obsolete. Newsgroup: comp.os.minix. 1992-01-29 [2006-11-27]. 12595@star.cs.vu.nl. （原始內容存檔於2013-05-26）. 
  26. ^ Torvalds, Linus. Hybrid kernel, not NT. 2006-05-09 [2007-01-06]. （原始內容存檔於2007-01-02）. 
  27. ^ Tanenbaum, Andy. Tanenbaum-Torvalds Debate: Part II. 2006-05-12 [2007-01-06]. （原始內容存檔於2015-08-05）. 
  28. ^ FAQ: Preemption. kernelnewbies.org. 2009-08-22 [2015-05-07]. （原始內容存檔於2020-08-07）. 
  29. ^ 29.0 29.1 Jonathan Corbet. Driver porting: the preemptible kernel. LWN.net. 2003-02-24 [2015-05-07]. （原始內容存檔於2020-08-10）. 
  30. ^ Jake Edge. Character devices in user space. LWN.net. 2008-11-25 [2015-05-07]. （原始內容存檔於2021-01-26）. 
  31. ^ Jonathan Corbet. UIO: user-space drivers. LWN.net. 2007-05-02 [2015-05-07]. （原始內容存檔於2020-11-11）. 
  32. ^ Kroah-Hartman, Greg. The Linux Kernel Driver Interface. [2018-12-19]. （原始內容存檔於2013-11-04）. 
  33. ^ 33.0 33.1 Nguyen, Binh. Linux Filesystem Hierarchy: Chapter 1. Linux Filesystem Hierarchy. The Linux Documentation Project. 2004-07-30 [2012-11-28]. （原始內容存檔於2020-12-02）. 
  34. ^ Ingo A. Kubbilun. Linux kernel patch for Intel Compiler. Pyrillion.org. 2004-06-02 [2010-11-12]. （原始內容存檔於2011-07-22）. 
  35. ^ High Performance Linux Kernel Project—LinuxDNA. Linux.slashdot.org. [2010-10-30]. （原始內容存檔於2019-10-18）. 
  36. ^ LinuxDNA Supercharges Linux with the Intel C/C++ Compiler. Linux Journal. [2010-10-30]. （原始內容存檔於2020-11-09）. 
  37. ^ Lelbach, Bryce. Clang builds a working Linux Kernel (Boots to RL5 with SMP, networking and X, self hosts). cfe-dev (郵寄清單). 2010-10-25 [2018-12-19]. （原始內容存檔於2015-09-07）. 
  38. ^ Larabel, Michael. Linux 3.15 Can Almost Be Compiled Under LLVM's Clang. Phoronix. 2014-04-12 [2014-06-10]. （原始內容存檔於2020-08-13）. 
  39. ^ Larabel, Michael. Patch By Patch, LLVM Clang Gets Better At Building The Linux Kernel. Phoronix. [2014-11-20]. （原始內容存檔於2020-08-13）. 
  40. ^ Edge, Jake. LFCS: The LLVMLinux project. LWN.net. 2013-05-07 [2015-03-03]. （原始內容存檔於2020-08-10）. 
  41. ^ Möller, Jan-Simon. LLVMLinux: The Linux Kernel with Dragon Wings (PDF). LLVM Project. 2014-02-02 [2015-03-03]. （原始內容存檔 (PDF)於2020-08-03）. 
  42. ^ ControlGroupInterface. freedesktop.org. [2018-12-22]. （原始內容存檔於2020-11-30）. 
  43. ^ libevdev. freedesktop.org. [2018-12-22]. （原始內容存檔於2020-09-30）. 
  44. ^ Greg Kroah-Hartman. The Linux Kernel Driver Interface. [2015-04-10]. （原始內容存檔於2013-11-04）. 
  45. ^ About mac80211. Linux Kernel Organization, Inc. [2014-06-08]. （原始內容存檔於2021-02-01）. 
  46. ^ Report on ABI changes in the Linux kernel. Andrey Ponomarenko's ABI laboratory. 2016-03-17 [2018-12-19]. （原始內容存檔於2016-03-12）. 
  47. ^ Werner Fischer; Georg Schönberger. Linux Storage Stack Diagram. Thomas-Krenn AG. 2015-06-01 [2015-06-08]. （原始內容存檔於2019-06-29）. 
  48. ^ Bovet, Daniel P.; Cesati, Marco. Chapter 10: Process Scheduling. Understanding the Linux Kernel. O'Reilly. October 2000 [2011-10-15]. ISBN 0-596-00002-2. （原始內容存檔於2014-09-21）. 
  49. ^ Santhanam, Anand. Towards Linux 2.6, A look into the workings of the next new kernel. IBM Global Services. 2003-09-23 [2011-10-15]. （原始內容存檔於2013-09-27）. 
  50. ^ 50.0 50.1 Bar, Moshe. The Linux Scheduler. Linux Journal. Belltown Media, Inc. 2000-04-01 [2012-04-14]. （原始內容存檔於2021-02-02）. 
  51. ^ Molnár, Ingo. [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]. LKML (郵寄清單). 2007-04-13 [2012-04-14]. （原始內容存檔於2020-11-03）. 
  52. ^ IEEE Standard for Information Technology – Portable Operating System Interface, POSIX.1b, Real-time extensions (IEEE Std 1003.1b-1993). [2018-12-08]. （原始內容存檔於2010-11-16）. 
  53. ^ McKenney, Paul. A realtime preemption overview. LWN.net. 2005-08-10 [2012-02-05]. （原始內容存檔於2020-08-10）. 
  54. ^ OSADL Project: Realtime Linux. OSADL. [2012-02-05]. （原始內容存檔於2021-02-04）. 
  55. ^ Bergmann, Arnd. BKL: That's all, folks. Linux Kernel Organization, Inc. 2011-03-05 [2012-02-20]. （原始內容存檔於2012-07-20）. 
  56. ^ Larabel, Michael. The Linux 3.14 Kernel Already Has Many Exciting Features. Phoronix. 2014-01-24 [2014-02-03]. （原始內容存檔於2020-08-13）. 
  57. ^ Linux kernel 3.14, Section 1.1. Deadline scheduling class for better real-time scheduling. kernelnewbies.org. 2014-03-30 [2014-04-02]. （原始內容存檔於2021-01-15）. 
  58. ^ TOP500 Statistics. Top500. [2012-04-26]. （原始內容存檔於2012-11-02）. 
  59. ^ Greg Kroah-Hartman. Android and the Linux kernel community. 2010-02-02 [2010-02-03]. （原始內容存檔於2019-04-27）. This means that any drivers written for Android hardware platforms, can not get merged into the main kernel tree because they have dependencies on code that only lives in Google's kernel tree, causing it to fail to build in the kernel.org tree. Because of this, Google has now prevented a large chunk of hardware drivers and platform code from ever getting merged into the main kernel tree. Effectively creating a kernel branch that a number of different vendors are now relying on. 
  60. ^ Linux developer explains Android kernel code removal. ZDNet. 2010-02-02 [2010-02-03]. （原始內容存檔於2010-02-06）. 
  61. ^ Maemo platform described as being based on Linux kernel. Maemo community. 2010-04-09 [2010-04-09]. （原始內容存檔於2020-09-27）. 
  62. ^ K.K. Mookhey, Nilesh Burghate and ISACA. Linux-- Security, Audit and Control Features. ISACA. 2005: 14 [2012-11-15]. ISBN 1-893209-78-4. （原始內容存檔於2020-08-04）. 
  63. ^ Brian Hatch. Hacking exposed Linux: Linux security secrets & solutions. McGraw Hill Professional. 2008: 524 [2012-11-15]. ISBN 0-07-226257-5. （原始內容存檔於2020-08-04）. 
  64. ^ Trent Jaeger. Operating system security. Morgan & Claypool Publishers. 2008: 122 [2012-11-15]. ISBN 1-59829-212-9. （原始內容存檔於2021-01-26）. 
  65. ^ Jeremy Andrews. Security Bugs and Full Disclosure. 2008-07-16 [2010-12-31]. （原始內容存檔於2012-07-10）. 
  66. ^ Brad Spengler. Linux's unofficial security-through-coverup policy. Full-Disclosure (郵寄清單). 2008-07-16 [2010-12-31]. （原始內容存檔於2020-08-07）. 
  67. ^ The Intel SYSRET privilege escalation –. Blog.xen.org. 2012-06-13 [2012-07-26]. （原始內容存檔於2012-06-16）. 
  68. ^ 陳曉莉. 把漏洞導入Linux核心來作實驗，Linux大佬封殺明尼蘇達大學所有貢獻. ithome. 2021-04-22 [2021-04-22]. （原始內容存檔於2021-04-27）. 
  69. ^ 69.0 69.1 Marti, Don. Are top Linux developers losing the will to code?. ComputerworldUK. [2016-10-24]. （原始內容存檔於2019-06-12） （英國英語）. 
  70. ^ How the development process works. [2018-02-04]. （原始內容存檔於2017-12-09）. 
  71. ^ Sharwood, Simon. Linux kernel dev who asked Linus Torvalds to stop verbal abuse quits over verbal abuse. The Register. 2015-10-06 [2018-02-19]. （原始內容存檔於2020-03-29）. 
  72. ^ Corbet, Jonathan. Bash the kernel maintainers. LWN.net. 2017-11-06 [2018-02-04]. （原始內容存檔於2021-01-26）. 
  73. ^ Code of Conflict. [2018-02-04]. [永久失效連結]
  74. ^ Edge, Jake. Too many lords, not enough stewards. LWN.net. 2018-01-31 [2018-02-04]. （原始內容存檔於2020-11-09）. 
  75. ^ Billimoria, Kaiwan N. Linux Kernel Programming A Comprehensive Guide to Kernel Internals, Writing Kernel Modules, and Kernel Synchronization.. Birmingham: Packt Publishing, Limited. 2021: 55. ISBN 978-1-78995-592-7. OCLC 1240585605. 
  76. ^ Vaduva, Alexandru. Linux : embedded development : leverage the power of Linux to develop captivating and powerful embedded Linux projects : a course in three modules. Alex Gonzalez, Chris Simmonds. Birmingham, UK. 2016: 663. ISBN 978-1-78712-445-5. OCLC 960471438. 
  77. ^ Karim Yaghmour. Building embedded Linux systems 2nd. Sebastopol [Calif.]: O'Reilly Media. 2008: 387. ISBN 978-0-596-52968-0. OCLC 273049576. 
  78. ^ Yaghmour, Karim. Embedded Android. Sebastopol, CA: O'Reilly Media. 2011: 44. ISBN 978-1-4493-2798-9. OCLC 812180000. 
  79. ^ SoC (System on a Chip). OpenWrt Wiki. 2014-11-06 [2021-03-15]. （原始內容存檔於2022-08-23） （英語）. 
  80. ^ David A. Wheeler. Linux Kernel 2.6: It's Worth More!. [2012-11-15]. （原始內容存檔於2011-08-21）. 
  81. ^ Economic impact of FLOSS on innovation and competitiveness of the EU ICT sector （頁面存檔備份，存於互聯網檔案館）, Table 3 on page 50.
  82. ^ Wheeler, David. The Linux Kernel: It’s Worth More!. [2012-09-17]. （原始內容存檔於2011-08-21）. 
  83. ^ Linux Kernel Archives - Volume 1 Archive.is的存檔，存檔日期2005-05-11（Riley Williams）
  84. ^ 84.0 84.1 Yamagata, Hiroo. The Pragmatist of Free Software. HotWired. 1997-08-03 [2007-02-21]. （原始內容存檔於2007-02-10）. 
  85. ^ Corbet, Jonathan. GPLv3 and the kernel. LWN.net. 2006-01-31 [2007-02-21]. （原始內容存檔於2020-08-10）. 
  86. ^ Torvalds, Linus. Linux-2.4.0-test8. LKML (郵寄清單). 2000-09-08 [2007-02-21]. （原始內容存檔於2020-05-15）. 
  87. ^ gnu.org. www.gnu.org. [2017-10-18]. （原始內容存檔於2021-02-02） （英語）. 
  88. ^ Cox, Alan. Re: GPL V3 and Linux. LKML (郵寄清單). 2006-01-20 [2007-02-21]. （原始內容存檔於2021-01-26）. 
  89. ^ Shankland, Stephen. Top Linux programmers pan GPL 3. News.com. CNET. 2006-09-25 [2007-02-21]. [失效連結]
  90. ^ 90.0 90.1 James E.J. Bottomley, Mauro Carvalho Chehab, Thomas Gleixner, Christoph Hellwig, Dave Jones, Greg Kroah-Hartman, Tony Luck, Andrew Morton, Trond Myklebust, David Woodhouse. Kernel developers' position on GPLv3: The Dangers and Problems with GPLv3. LWN.net. 2006-09-15 [2015-03-11]. （原始內容存檔於2021-01-18）. The current version (Discussion Draft 2) of GPLv3 on first reading fails the necessity test of section 1 on the grounds that there's no substantial and identified problem with GPLv2 that it is trying to solve. However, a deeper reading reveals several other problems with the current FSF draft: 5.1 DRM Clauses [...] 5.2 Additional Restrictions Clause [...] 5.3 Patents Provisions [...] since the FSF is proposing to shift all of its projects to GPLv3 and apply pressure to every other GPL licensed project to move, we foresee the release of GPLv3 portends the Balkanisation of the entire Open Source Universe upon which we rely. 
  91. ^ Petreley, Nicholas. A fight against evil or a fight for attention?. linuxjournal.com. 2006-09-27 [2015-03-11]. （原始內容存檔於2018-03-02）. Second, the war between Linus Torvalds and other Kernel developers and the Free Software Foundation over GPLv3 is continuing, with Torvalds saying he's fed up with the FSF. 
  92. ^ Linus Torvalds says GPL v3 violates everything that GPLv2 stood for （頁面存檔備份，存於互聯網檔案館） Debconf 2014, Portland, Oregon (accessed 11 March 2015)
  93. ^ 存档副本. [2006-11-25]. （原始內容存檔於2013-06-23）. 
  94. ^ 存档副本. [2006-11-25]. （原始內容存檔於2006-09-27）. 

外部連結

編輯
 
維基共享資源中相關的多媒體資源：Linux內核
取自 "https://zh.wiki.x.io/w/index.php?title=Linux内核&oldid=84721636"