linux 内核是什么， 本人有linux基础

Linux内核：Linux是一种开源电脑 *** 作系统内核。它是一个用C语言写成，符合POSIX标准的类Unix *** 作系统。Linux最早是由芬兰 Linus Torvalds为尝试在英特尔x86架构上提供自由的类Unix *** 作系统而开发的。该计划开始于1991年，在计划的早期有一些Minix 黑客提供了协助，而今天全球无数程序员正在为该计划无偿提供帮助。

Linux最早是由芬兰人Linus Torvalds设计的。当时由于UNⅨ的商业化，Andrew Tannebaum教授开发了Minix *** 作系统以便于不受AT&T许可协议的约束，为教学科研提供一个 *** 作系统。

扩展资料：

Linux将标准的GNU许可协议改称Copyleft，以便与Copyright相对照。通用的公共许可（GPL）允许用户销售、拷贝和改变具有Copyleft的应用程序。当然这些程序也可以是Copyright的，但是你必须允许进一步的销售、拷贝和对其代码进行改变，同时也必须使他人可以免费得到修改后的源代码。事实证明，GPL对于Linux的成功起到了极大的作用。它启动了一个十分繁荣的商用Linux阶段，还为编程人员提供了一种凝聚力，诱使大家加入这个充满了慈善精神的Linux运动。

参考资料来源：百度百科-Linux

参考资料来源：百度百科-内核

1.2.1 调度过程中关闭内核抢占

我们在上一篇linux内核主调度器schedule(文章链接, CSDN, Github)中在分析主调度器的时候, 我们会发现内核在进行调度之前都会通过preempt_disable关闭内核抢占, 而在完成调度工作后, 又会重新开启内核抢占

参见主调度器函数schedule

do {

preempt_disable() /* 关闭内核抢占 */

__schedule(false) /* 完成调度 */

sched_preempt_enable_no_resched() /* 开启内核抢占 */

} while (need_resched()) /* 如果该进程被其他进程设置了TIF_NEED_RESCHED标志，则函数重新执行进行调度*/123456123456

这个很容易理解, 我们在内核完成调度器过程中, 这时候如果发生了内核抢占, 我们的调度会被中断, 而调度却还没有完成, 这样会丢失我们调度的信息.

1.2.2 调度完成检查need_resched看是否需要重新调度

而同样我们可以看到, 在调度完成后, 内核会去判断need_resched条件, 如果这个时候为真, 内核会重新进程一次调度.

这个的原因, 我们在前一篇博客中, 也已经说的很明白了,

内核在thread_info的flag中设置了一个标识来标志进程是否需要重新调度, 即重新调度need_resched标识TIF_NEED_RESCHED, 内核在即将返回用户空间时会检查标识TIF_NEED_RESCHED标志进程是否需要重新调度，如果设置了，就会发生调度, 这被称为用户抢占

2 非抢占式和可抢占式内核

为了简化问题，我使用嵌入式实时系统uC/OS作为例子

首先要指出的是，uC/OS只有内核态，没有用户态，这和Linux不一样

多任务系统中, 内核负责管理各个任务, 或者说为每个任务分配CPU时间, 并且负责任务之间的通讯.

内核提供的基本服务是任务切换. 调度（Scheduler）,英文还有一词叫dispatcher, 也是调度的意思.

这是内核的主要职责之一, 就是要决定该轮到哪个任务运行了. 多数实时内核是基于优先级调度法的, 每个任务根据其重要程度的不同被赋予一定的优先级. 基于优先级的调度法指，CPU总是让处在就绪态的优先级最高的任务先运行. 然而, 究竟何时让高优先级任务掌握CPU的使用权, 有两种不同的情况, 这要看用的是什么类型的内核, 是不可剥夺型的还是可剥夺型内核

2.1 非抢占式内核

非抢占式内核是由任务主动放弃CPU的使用权

非抢占式调度法也称作合作型多任务, 各个任务彼此合作共享一个CPU. 异步事件还是由中断服务来处理. 中断服务可以使一个高优先级的任务由挂起状态变为就绪状态.

但中断服务以后控制权还是回到原来被中断了的那个任务, 直到该任务主动放弃CPU的使用权时，那个高优先级的任务才能获得CPU的使用权。非抢占式内核如下图所示.

非抢占式内核的优点有

中断响应快(与抢占式内核比较)；

允许使用不可重入函数；

几乎不需要使用信号量保护共享数据, 运行的任务占有CPU，不必担心被别的任务抢占。这不是绝对的，在打印机的使用上，仍需要满足互斥条件。

非抢占式内核的缺点有

任务响应时间慢。高优先级的任务已经进入就绪态，但还不能运行，要等到当前运行着的任务释放CPU

非抢占式内核的任务级响应时间是不确定的，不知道什么时候最高优先级的任务才能拿到CPU的控制权，完全取决于应用程序什么时候释放CPU

2.2 抢占式内核

使用抢占式内核可以保证系统响应时间. 最高优先级的任务一旦就绪, 总能得到CPU的使用权。当一个运行着的任务使一个比它优先级高的任务进入了就绪态, 当前任务的CPU使用权就会被剥夺，或者说被挂起了，那个高优先级的任务立刻得到了CPU的控制权。如果是中断服务子程序使一个高优先级的任务进入就绪态，中断完成时，中断了的任务被挂起，优先级高的那个任务开始运行。

抢占式内核如下图所示

抢占式内核的优点有

使用抢占式内核，最高优先级的任务什么时候可以执行，可以得到CPU的使用权是可知的。使用抢占式内核使得任务级响应时间得以最优化。

抢占式内核的缺点有：

不能直接使用不可重入型函数。调用不可重入函数时，要满足互斥条件，这点可以使用互斥型信号量来实现。如果调用不可重入型函数时，低优先级的任务CPU的使用权被高优先级任务剥夺，不可重入型函数中的数据有可能被破坏。

3 linux用户抢占

3.1 linux用户抢占

当内核即将返回用户空间时, 内核会检查need_resched是否设置, 如果设置, 则调用schedule()，此时，发生用户抢占.

3.2 need_resched标识

内核如何检查一个进程是否需要被调度呢?

内核在即将返回用户空间时检查进程是否需要重新调度，如果设置了，就会发生调度, 这被称为用户抢占, 因此内核在thread_info的flag中设置了一个标识来标志进程是否需要重新调度, 即重新调度need_resched标识TIF_NEED_RESCHED

并提供了一些设置可检测的函数

函数

描述

定义

set_tsk_need_resched设置指定进程中的need_resched标志include/linux/sched.h, L2920

clear_tsk_need_resched清除指定进程中的need_resched标志include/linux/sched.h, L2926

test_tsk_need_resched检查指定进程need_resched标志include/linux/sched.h, L2931

而我们内核中调度时常用的need_resched()函数检查进程是否需要被重新调度其实就是通过test_tsk_need_resched实现的, 其定义如下所示

// http://lxr.free-electrons.com/source/include/linux/sched.h?v=4.6#L3093

static __always_inline bool need_resched(void)

{

return unlikely(tif_need_resched())

}

// http://lxr.free-electrons.com/source/include/linux/thread_info.h?v=4.6#L106

#define tif_need_resched() test_thread_flag(TIF_NEED_RESCHED)1234567812345678

3.3 用户抢占的发生时机(什么时候需要重新调度need_resched)

一般来说，用户抢占发生几下情况：

从系统调用返回用户空间；

从中断(异常)处理程序返回用户空间

从这里我们可以看到, 用户抢占是发生在用户空间的抢占现象.

更详细的触发条件如下所示, 其实不外乎就是前面所说的两种情况: 从系统调用或者中断返回用户空间

时钟中断处理例程检查当前任务的时间片，当任务的时间片消耗完时，scheduler_tick()函数就会设置need_resched标志；

信号量、等到队列、completion等机制唤醒时都是基于waitqueue的，而waitqueue的唤醒函数为default_wake_function，其调用try_to_wake_up将被唤醒的任务更改为就绪状态并设置need_resched标志。

设置用户进程的nice值时，可能会使高优先级的任务进入就绪状态；

改变任务的优先级时，可能会使高优先级的任务进入就绪状态；

新建一个任务时，可能会使高优先级的任务进入就绪状态；

对CPU(SMP)进行负载均衡时，当前任务可能需要放到另外一个CPU上运行

4 linux内核抢占

4.1 内核抢占的概念

对比用户抢占, 顾名思义, 内核抢占就是指一个在内核态运行的进程, 可能在执行内核函数期间被另一个进程取代.

4.2 为什么linux需要内核抢占

linux系统中, 进程在系统调用后返回用户态之前, 或者是内核中某些特定的点上, 都会调用调度器. 这确保除了一些明确指定的情况之外, 内核是无法中断的, 这不同于用户进程.

如果内核处于相对耗时的 *** 作中, 比如文件系统或者内存管理相关的任务, 这种行为可能会带来问题. 这种情况下, 内核代替特定的进程执行相当长的时间, 而其他进程无法执行, 无法调度, 这就造成了系统的延迟增加, 用户体验到”缓慢”的响应. 比如如果多媒体应用长时间无法得到CPU, 则可能发生视频和音频漏失现象.

在编译内核时如果启用了对内核抢占的支持, 则可以解决这些问题. 如果高优先级进程有事情需要完成, 那么在启用了内核抢占的情况下, 不仅用户空间应用程序可以被中断, 内核也可以被中断,

linux内核抢占是在Linux2.5.4版本发布时加入的, 尽管使内核可抢占需要的改动特别少, 但是该机制不像抢占用户空间进程那样容易实现. 如果内核无法一次性完成某些 *** 作(例如, 对数据结构的 *** 作), 那么可能出现静态条件而使得系统不一致.

内核抢占和用户层进程被其他进程抢占是两个不同的概念, 内核抢占主要是从实时系统中引入的, 在非实时系统中的确也能提高系统的响应速度, 但也不是在所有情况下都是最优的，因为抢占也需要调度和同步开销，在某些情况下甚至要关闭内核抢占, 比如前面我们将主调度器的时候, linux内核在完成调度的过程中是关闭了内核抢占的.

内核不能再任意点被中断, 幸运的是, 大多数不能中断的点已经被SMP实现标识出来了. 并且在实现内核抢占时可以重用这些信息. 如果内核可以被抢占, 那么单处理器系统也会像是一个SMP系统

4.3 内核抢占的发生时机

要满足什么条件，kernel才可以抢占一个任务的内核态呢?

没持有锁。锁是用于保护临界区的，不能被抢占。

Kernel code可重入(reentrant)。因为kernel是SMP-safe的，所以满足可重入性。

内核抢占发生的时机，一般发生在：

当从中断处理程序正在执行，且返回内核空间之前。当一个中断处理例程退出，在返回到内核态时(kernel-space)。这是隐式的调用schedule()函数，当前任务没有主动放弃CPU使用权，而是被剥夺了CPU使用权。

当内核代码再一次具有可抢占性的时候，如解锁（spin_unlock_bh）及使能软中断(local_bh_enable)等, 此时当kernel code从不可抢占状态变为可抢占状态时(preemptible again)。也就是preempt_count从正整数变为0时。这也是隐式的调用schedule()函数

如果内核中的任务显式的调用schedule(), 任务主动放弃CPU使用权

如果内核中的任务阻塞(这同样也会导致调用schedule()), 导致需要调用schedule()函数。任务主动放弃CPU使用权

内核抢占，并不是在任何一个地方都可以发生，以下情况不能发生

内核正进行中断处理。在Linux内核中进程不能抢占中断(中断只能被其他中断中止、抢占，进程不能中止、抢占中断)，在中断例程中不允许进行进程调度。进程调度函数schedule()会对此作出判断，如果是在中断中调用，会打印出错信息。

内核正在进行中断上下文的Bottom Half(中断下半部，即软中断)处理。硬件中断返回前会执行软中断，此时仍然处于中断上下文中。如果此时正在执行其它软中断，则不再执行该软中断。

内核的代码段正持有spinlock自旋锁、writelock/readlock读写锁等锁，处干这些锁的保护状态中。内核中的这些锁是为了在SMP系统中短时间内保证不同CPU上运行的进程并发执行的正确性。当持有这些锁时，内核不应该被抢占。

内核正在执行调度程序Scheduler。抢占的原因就是为了进行新的调度，没有理由将调度程序抢占掉再运行调度程序。

内核正在对每个CPU“私有”的数据结构 *** 作(Per-CPU date structures)。在SMP中，对于per-CPU数据结构未用spinlocks保护，因为这些数据结构隐含地被保护了(不同的CPU有不一样的per-CPU数据，其他CPU上运行的进程不会用到另一个CPU的per-CPU数据)。但是如果允许抢占，但一个进程被抢占后重新调度，有可能调度到其他的CPU上去，这时定义的Per-CPU变量就会有问题，这时应禁抢占。

如何参与Linux内核开发

---------------------

这是一篇将如何参与Linux内核开发的相关问题一网打尽的终极秘笈。它将指导你

成为一名Linux内核开发者，并且学会如何同Linux内核开发社区合作。它尽可能不

包括任何关于内核编程的技术细节，但会给你指引一条获得这些知识的正确途径。

如果这篇文章中的任何内容不再适用，请给文末列出的文件维护者发送补丁。

入门

----

你想了解如何成为一名Linux内核开发者？或者老板吩咐你“给这个设备写个Linux

驱动程序”？这篇文章的目的就是教会你达成这些目标的全部诀窍，它将描述你需

要经过的流程以及给出如何同内核社区合作的一些提示。它还将试图解释内核社区

为何这样运作。

Linux内核大部分是由C语言写成的，一些体系结构相关的代码用到了汇编语言。要

参与内核开发，你必须精通C语言。除非你想为某个架构开发底层代码，否则你并

不需要了解（任何体系结构的）汇编语言。下面列举的书籍虽然不能替代扎实的C

语言教育和多年的开发经验，但如果需要的话，做为参考还是不错的：

- "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]

《C程序设计语言（第2版·新版）》（徐宝文 李志 译）[机械工业出版社]

- "Practical C Programming" by Steve Oualline [O'Reilly]

《实用C语言编程（第三版）》（郭大海 译）[中国电力出版社]

- "C: A Reference Manual" by Harbison and Steele [Prentice Hall]

《C语言参考手册（原书第5版）》（邱仲潘 等译）[机械工业出版社]

Linux内核使用GNU C和GNU工具链开发。虽然它遵循ISO C89标准，但也用到了一些

标准中没有定义的扩展。内核是自给自足的C环境，不依赖于标准C库的支持，所以

并不支持C标准中的部分定义。比如long long类型的大数除法和浮点运算就不允许

使用。有时候确实很难弄清楚内核对工具链的要求和它所使用的扩展，不幸的是目

前还没有明确的参考资料可以解释它们。请查阅gcc信息页（使用“info gcc”命令

显示）获得一些这方面信息。

请记住你是在学习怎么和已经存在的开发社区打交道。它由一群形形色色的人组成，

他们对代码、风格和过程有着很高的标准。这些标准是在长期实践中总结出来的，

适应于地理上分散的大型开发团队。它们已经被很好得整理成档，建议你在开发

之前尽可能多的学习这些标准，而不要期望别人来适应你或者你公司的行为方式。

法律问题

--------

Linux内核源代码都是在GPL（通用公共许可证）的保护下发布的。要了解这种许可

的细节请查看源代码主目录下的COPYING文件。如果你对它还有更深入问题请联系

律师，而不要在Linux内核邮件组上提问。因为邮件组里的人并不是律师，不要期

望他们的话有法律效力。

对于GPL的常见问题和解答，请访问以下链接：

http://www.gnu.org/licenses/gpl-faq.html

文档

----

Linux内核代码中包含有大量的文档。这些文档对于学习如何与内核社区互动有着

不可估量的价值。当一个新的功能被加入内核，最好把解释如何使用这个功能的文

档也放进内核。当内核的改动导致面向用户空间的接口发生变化时，最好将相关信

息或手册页(manpages)的补丁发到mtk.manpages@gmail.com，以向手册页(manpages)

的维护者解释这些变化。

以下是内核代码中需要阅读的文档：

README

文件简要介绍了Linux内核的背景，并且描述了如何配置和编译内核。内核的

新用户应该从这里开始。

Documentation/Changes

文件给出了用来编译和使用内核所需要的最小软件包列表。

Documentation/CodingStyle

描述Linux内核的代码风格和理由。所有新代码需要遵守这篇文档中定义的规

范。大多数维护者只会接收符合规定的补丁，很多人也只会帮忙检查符合风格

的代码。

Documentation/SubmittingPatches

Documentation/SubmittingDrivers

这两份文档明确描述如何创建和发送补丁，其中包括（但不仅限于)：

- 邮件内容

- 邮件格式

- 选择收件人

遵守这些规定并不能保证提交成功（因为所有补丁需要通过严格的内容和风格

审查），但是忽视他们几乎就意味着失败。

其他关于如何正确地生成补丁的优秀文档包括：

"The Perfect Patch"

http://userweb.kernel.org/~akpm/stuff/tpp.txt

"Linux kernel patch submission format"

http://linux.yyz.us/patch-format.html

Documentation/stable_api_nonsense.txt

论证内核为什么特意不包括稳定的内核内部API，也就是说不包括像这样的特

性：

- 子系统中间层（为了兼容性？）

- 在不同 *** 作系统间易于移植的驱动程序

- 减缓（甚至阻止）内核代码的快速变化

这篇文档对于理解Linux的开发哲学至关重要。对于将开发平台从其他 *** 作系

统转移到Linux的人来说也很重要。

Documentation/SecurityBugs

如果你认为自己发现了Linux内核的安全性问题，请根据这篇文档中的步骤来

提醒其他内核开发者并帮助解决这个问题。

Documentation/ManagementStyle

描述内核维护者的工作方法及其共有特点。这对于刚刚接触内核开发（或者对

它感到好奇）的人来说很重要，因为它解释了很多对于内核维护者独特行为的

普遍误解与迷惑。

Documentation/stable_kernel_rules.txt

解释了稳定版内核发布的规则，以及如何将改动放入这些版本的步骤。

Documentation/kernel-docs.txt

有助于内核开发的外部文档列表。如果你在内核自带的文档中没有找到你想找

的内容，可以查看这些文档。

Documentation/applying-patches.txt

关于补丁是什么以及如何将它打在不同内核开发分支上的好介绍

内核还拥有大量从代码自动生成的文档。它包含内核内部API的全面介绍以及如何

妥善处理加锁的规则。生成的文档会放在 Documentation/DocBook/目录下。在内

核源码的主目录中使用以下不同命令将会分别生成PDF、Postscript、HTML和手册

页等不同格式的文档：

make pdfdocs

make psdocs

make htmldocs

make mandocs

如何成为内核开发者

------------------

如果你对Linux内核开发一无所知，你应该访问“Linux内核新手”计划：

http://kernelnewbies.org

它拥有一个可以问各种最基本的内核开发问题的邮件列表（在提问之前一定要记得

查找已往的邮件，确认是否有人已经回答过相同的问题）。它还拥有一个可以获得

实时反馈的IRC聊天频道，以及大量对于学习Linux内核开发相当有帮助的文档。

网站简要介绍了源代码组织结构、子系统划分以及目前正在进行的项目（包括内核

中的和单独维护的）。它还提供了一些基本的帮助信息，比如如何编译内核和打补

丁。

如果你想加入内核开发社区并协助完成一些任务，却找不到从哪里开始，可以访问

“Linux内核房管员”计划：

http://kernelnewbies.org/KernelJanitors

这是极佳的起点。它提供一个相对简单的任务列表，列出内核代码中需要被重新

整理或者改正的地方。通过和负责这个计划的开发者们一同工作，你会学到将补丁

集成进内核的基本原理。如果还没有决定下一步要做什么的话，你还可能会得到方

向性的指点。

如果你已经有一些现成的代码想要放到内核中，但是需要一些帮助来使它们拥有正

确的格式。请访问“内核导师”计划。这个计划就是用来帮助你完成这个目标的。它

是一个邮件列表，地址如下：

http://selenic.com/mailman/listinfo/kernel-mentors

在真正动手修改内核代码之前，理解要修改的代码如何运作是必需的。要达到这个

目的，没什么办法比直接读代码更有效了（大多数花招都会有相应的注释），而且

一些特制的工具还可以提供帮助。例如，“Linux代码交叉引用”项目就是一个值得

特别推荐的帮助工具，它将源代码显示在有编目和索引的网页上。其中一个更新及

时的内核源码库，可以通过以下地址访问：

http://sosdg.org/~coywolf/lxr/

开发流程

--------

目前Linux内核开发流程包括几个“主内核分支”和很多子系统相关的内核分支。这

些分支包括：

- 2.6.x主内核源码树

- 2.6.x.y -stable内核源码树

- 2.6.x -git内核补丁集

- 2.6.x -mm内核补丁集

- 子系统相关的内核源码树和补丁集

2.6.x内核主源码树

-----------------

2.6.x内核是由Linus Torvalds（Linux的创造者）亲自维护的。你可以在

kernel.org网站的pub/linux/kernel/v2.6/目录下找到它。它的开发遵循以下步

骤：

- 每当一个新版本的内核被发布，为期两周的集成窗口将被打开。在这段时间里

维护者可以向Linus提交大段的修改，通常这些修改已经被放到-mm内核中几个

星期了。提交大量修改的首选方式是使用git工具（内核的代码版本管理工具

，更多的信息可以在http://git.or.cz/获取），不过使用普通补丁也是可以

的。

- 两个星期以后-rc1版本内核发布。之后只有不包含可能影响整个内核稳定性的

新功能的补丁才可能被接受。请注意一个全新的驱动程序（或者文件系统）有

可能在-rc1后被接受是因为这样的修改完全独立，不会影响其他的代码，所以

没有造成内核退步的风险。在-rc1以后也可以用git向Linus提交补丁，不过所

有的补丁需要同时被发送到相应的公众邮件列表以征询意见。

- 当Linus认为当前的git源码树已经达到一个合理健全的状态足以发布供人测试

时，一个新的-rc版本就会被发布。计划是每周都发布新的-rc版本。

- 这个过程一直持续下去直到内核被认为达到足够稳定的状态，持续时间大概是

6个星期。

- 以下地址跟踪了在每个-rc发布中发现的退步列表：

http://kernelnewbies.org/known_regressions

关于内核发布，值得一提的是Andrew Morton在linux-kernel邮件列表中如是说：

“没有人知道新内核何时会被发布，因为发布是根据已知bug的情况来决定

的，而不是根据一个事先制定好的时间表。”

2.6.x.y -stable（稳定版）内核源码树

-----------------------------------

由4个数字组成的内核版本号说明此内核是-stable版本。它们包含基于2.6.x版本

内核的相对较小且至关重要的修补，这些修补针对安全性问题或者严重的内核退步。

这种版本的内核适用于那些期望获得最新的稳定版内核并且不想参与测试开发版或

者实验版的用户。

如果没有2.6.x.y版本内核存在，那么最新的2.6.x版本内核就相当于是当前的稳定

版内核。

2.6.x.y版本由“稳定版”小组（邮件地址<stable@kernel.org>）维护，一般隔周发

布新版本。

内核源码中的Documentation/stable_kernel_rules.txt文件具体描述了可被稳定

版内核接受的修改类型以及发布的流程。

2.6.x -git补丁集

----------------

Linus的内核源码树的每日快照，这个源码树是由git工具管理的（由此得名）。这

些补丁通常每天更新以反映Linus的源码树的最新状态。它们比-rc版本的内核源码

树更具试验性质，因为这个补丁集是全自动生成的，没有任何人来确认其是否真正

健全。

2.6.x -mm补丁集

---------------

这是由Andrew Morton维护的试验性内核补丁集。Andrew将所有子系统的内核源码

和补丁拼凑到一起，并且加入了大量从linux-kernel邮件列表中采集的补丁。这个

源码树是新功能和补丁的试炼场。当补丁在-mm补丁集里证明了其价值以后Andrew

或者相应子系统的维护者会将补丁发给Linus以便集成进主内核源码树。

在将所有新补丁发给Linus以集成到主内核源码树之前，我们非常鼓励先把这些补

丁放在-mm版内核源码树中进行测试。

这些内核版本不适合在需要稳定运行的系统上运行，因为运行它们比运行任何其他

内核分支都更具有风险。

如果你想为内核开发进程提供帮助，请尝试并使用这些内核版本，并在

linux-kernel邮件列表中提供反馈，告诉大家你遇到了问题还是一切正常。

通常-mm版补丁集不光包括这些额外的试验性补丁，还包括发布时-git版主源码树

中的改动。

-mm版内核没有固定的发布周期，但是通常在每两个-rc版内核发布之间都会有若干

个-mm版内核发布（一般是1至3个）。

子系统相关内核源码树和补丁集

----------------------------

相当一部分内核子系统开发者会公开他们自己的开发源码树，以便其他人能了解内

核的不同领域正在发生的事情。如上所述，这些源码树会被集成到-mm版本内核中。

下面是目前可用的一些内核源码树的列表：

通过git管理的源码树：

- Kbuild开发源码树， Sam Ravnborg <sam@ravnborg.org>

git.kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git

- ACPI开发源码树, Len Brown <len.brown@intel.com>

git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git

- 块设备开发源码树, Jens Axboe <axboe@suse.de>

git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git

- DRM开发源码树, Dave Airlie <airlied@linux.ie>

git.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git

- ia64开发源码树, Tony Luck <tony.luck@intel.com>

git.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git

- ieee1394开发源码树, Jody McIntyre <scjody@modernduck.com>

git.kernel.org:/pub/scm/linux/kernel/git/scjody/ieee1394.git

- infiniband开发源码树, Roland Dreier <rolandd@cisco.com>

git.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git

- libata开发源码树, Jeff Garzik <jgarzik@pobox.com>

git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git

- 网络驱动程序开发源码树, Jeff Garzik <jgarzik@pobox.com>

git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git

- pcmcia开发源码树, Dominik Brodowski <linux@dominikbrodowski.net>

git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git

- SCSI开发源码树, James Bottomley <James.Bottomley@SteelEye.com>

git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git

使用quilt管理的补丁集：

- USB, PCI, 驱动程序核心和I2C, Greg Kroah-Hartman <gregkh@suse.de>

kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/

- x86-64, 部分i386, Andi Kleen <ak@suse.de>

ftp.firstfloor.org:/pub/ak/x86_64/quilt/

其他内核源码树可以在http://git.kernel.org的列表中和MAINTAINERS文件里

找到。

报告bug

-------

bugzilla.kernel.org是Linux内核开发者们用来跟踪内核Bug的网站。我们鼓励用

户在这个工具中报告找到的所有bug。如何使用内核bugzilla的细节请访问：

http://test.kernel.org/bugzilla/faq.html

内核源码主目录中的REPORTING-BUGS文件里有一个很好的模板。它指导用户如何报

告可能的内核bug以及需要提供哪些信息来帮助内核开发者们找到问题的根源。

利用bug报告

-----------

练习内核开发技能的最好办法就是修改其他人报告的bug。你不光可以帮助内核变

得更加稳定，还可以学会如何解决实际问题从而提高自己的技能，并且让其他开发

者感受到你的存在。修改bug是赢得其他开发者赞誉的最好办法，因为并不是很多

人都喜欢浪费时间去修改别人报告的bug。

要尝试修改已知的bug，请访问http://bugzilla.kernel.org网址。如果你想获得

最新bug的通知，可以订阅bugme-new邮件列表（只有新的bug报告会被寄到这里）

或者订阅bugme-janitor邮件列表（所有bugzilla的变动都会被寄到这里）。

https://lists.linux-foundation.org/mailman/listinfo/bugme-new

https://lists.linux-foundation.org/mailman/listinfo/bugme-janitors

邮件列表

--------

正如上面的文档所描述，大多数的骨干内核开发者都加入了Linux Kernel邮件列

表。如何订阅和退订列表的细节可以在这里找到：

http://vger.kernel.org/vger-lists.html#linux-kernel

网上很多地方都有这个邮件列表的存档(archive)。可以使用搜索引擎来找到这些

存档。比如：

http://dir.gmane.org/gmane.linux.kernel

在发信之前，我们强烈建议你先在存档中搜索你想要讨论的问题。很多已经被详细

讨论过的问题只在邮件列表的存档中可以找到。

大多数内核子系统也有自己独立的邮件列表来协调各自的开发工作。从

MAINTAINERS文件中可以找到不同话题对应的邮件列表。

很多邮件列表架设在kernel.org服务器上。这些列表的信息可以在这里找到：

http://vger.kernel.org/vger-lists.html

在使用这些邮件列表时，请记住保持良好的行为习惯。下面的链接提供了与这些列

表（或任何其它邮件列表）交流的一些简单规则，虽然内容有点滥竽充数。

http://www.albion.com/netiquette/

当有很多人回复你的邮件时，邮件的抄送列表会变得很长。请不要将任何人从抄送

列表中删除，除非你有足够的理由这么做。也不要只回复到邮件列表。请习惯于同

一封邮件接收两次（一封来自发送者一封来自邮件列表），而不要试图通过添加一

些奇特的邮件头来解决这个问题，人们不会喜欢的。

记住保留你所回复内容的上下文和源头。在你回复邮件的顶部保留“某某某说到……”

这几行。将你的评论加在被引用的段落之间而不要放在邮件的顶部。

如果你在邮件中附带补丁，请确认它们是可以直接阅读的纯文本（如

Documentation/SubmittingPatches文档中所述）。内核开发者们不希望遇到附件

或者被压缩了的补丁。只有这样才能保证他们可以直接评论你的每行代码。请确保

你使用的邮件发送程序不会修改空格和制表符。一个防范性的测试方法是先将邮件

发送给自己，然后自己尝试是否可以顺利地打上收到的补丁。如果测试不成功，请

调整或者更换你的邮件发送程序直到它正确工作为止。

总而言之，请尊重其他的邮件列表订阅者。

---