跳转到内容

Linux内核

本页使用了标题或全文手工转换
维基百科，自由的百科全书
  提示：此条目页的主题不是GNU/Linux或Linux-libre。
Linux
Linux官方的吉祥物，一隻叫Tux的企鵝
Linux内核3.0.0启动画面
开发者林納斯·托瓦茲（Linus Torvalds）和几千名合作者
编程语言C語言、Rust、汇编语言
作業系統家族类Unix系统
首次发布0.01（1991年9月17日，​33年前​（1991-09-17））
当前版本
  • 6.12-rc7（2024年11月10日；最终测试版本）[1]
  • 6.11.8（2024年11月14日；穩定版本）[2]
編輯維基數據鏈接
最新預覽Kernel: 6.2-rc5[3]（2023年1月21日，​21個月前​（2023-01-21））[±]
支持的语言多语言
内核类别單核心
许可证GPL（僅）第二版[4][5]，
各類封闭固件的許可證[6][7]
官方網站www.kernel.org 編輯維基數據鏈接
仓库
編輯維基數據鏈接

Linux内核（英語：Linux kernel）是一种开源的类Unix操作系统宏内核。整个Linux操作系统家族基于该内核部署在传统计算机平台（如个人计算机和服务器，以Linux发行版的形式[8]）和各种嵌入式平台，如路由器、无线接入点、专用小交换机、机顶盒、FTA接收器（英语：FTA receiver）、智能电视、数字视频录像机、网络附加存储（NAS）等。工作于平板電腦、智能手机及智能手表的Android操作系统同样通过Linux内核提供的服务完成自身功能。尽管于桌面电脑的占用率较低，基于Linux的操作系统统治了几乎从移动设备到主机的其他全部领域。截至2017年11月，世界前500台最强的超级计算机全部使用Linux。[9]

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-rc7. 2024年11月10日 [2024年11月10日]. 
  2. ^ 葛雷格·克羅哈曼. Linux 6.11.8. 2024年11月14日 [2024年11月14日]. 
  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.wikipedia.org/w/index.php?title=Linux内核&oldid=84721636”