基本概述编辑本段回目录
 |
| 内核 |
单内核编辑本段回目录
 |
| 单内核结构的操作系统 |
单内核为潜在的硬件提供了大量完善的硬件抽象操作。单内核结构在硬件之上定义了一个高阶的抽象界面，应用一组原语(或者叫系统调用)来实现操作系统的功能，例如进程管理，文件系统，和存储管理等等，这些功能由多个运行在核心态的模块来完成。尽管每一个模块都是单独地服务这些操作，内核代码是高度集成的，而且难以编写正确。因为所有的模块都在同一个内核空间上运行，一个很小的bug都会使整个系统崩溃。然而，如果开发顺利，单内核结构就可以从运行效率上得到好处。
很多现代的单内核结构内核，如Linux和FreeBSD内核，能够在运行时将模块调入执行，这就可以使扩充内核的功能变得更简单，也可以使内核的核心部分变得更简洁。
单内核结构的例子：1、传统的UNIX内核，例如伯克利大学发行的版本；2、Linux内核。
微内核编辑本段回目录
 |
| 具有安全权限限制的微内核 |
微内核的例子：
 |
| 第二代微内核操作系统设计理论设计 |
2、BeOS
3、L4微内核系列
4、Mach, 用于GNU Hurd和Mac OS X
5、Minix
6、MorphOS
7、QNX
8、RadiOS
9、VSTa
单内核与微内核的比较
单内核结构是非常有吸引力的一种设计，由于在同一个地址空间上实现所有低级操作的系统控制代码的复杂性的效率会比在不同地址空间上实现更高些。20世纪90年代初，单内核结构被认为是过时的。把Linux设计成为单内核结构而不是微内核引起了无数的争议。现在，单核结构正趋向于容易被正确设计，所以它的发展会比微内核结构更迅速些。两个阵营中都有成功的案例。微核经常被用于机器人和医疗器械的嵌入式设计中，因为它的系统的关键部分都处在相互分开的，被保护的存储空间中。这对于单核设计来说是不可能的，就算它采用了运行时加载模块的方式。尽管Mach是众所周知的多用途的微内核，人们还是开发了除此之外的几个微内核。L3是一个演示性的内核，只是为了证明微内核设计并不总是低运行速度。它的后续版本L4甚至可以将Linux内核在单独的地址空间作为它的一个进程来运行。
QNX是一个从20世纪80年代就开始设计的微内核系统。它比Mach更接近微内核的理念。它被用于一些特殊的领域，在这些情况下由于软件错误导致系统失效是不允许的。例如航天飞机上的机械手，还有研磨望远镜镜片的机器，一点点失误就会导致上千美元的损失。很多人相信，由于Mach不能够解决一些提出微内核理论时针对的问题，所以微内核技术毫无用处。Mach的爱好者表明这是非常狭隘的观点，遗憾的是似乎所有人都开始接受这种观点。
混合内核编辑本段回目录
 |
| 内核 |
混合内核很像微内核结构，只不过它的的组件更多的在核心态中运行，以获得更快的执行速度。
混合内核实质上是微内核，只不过它让一些微核结构运行在用户空间的代码运行在内核空间，这样让内核的运行效率更高些。这是一种妥协做法，设计者参考了微内核结构的系统运行速度不佳的理论。然而后来的实验证明，纯微内核的系统实际上也可以是高效率的。大多数现代操作系统遵循这种设计范畴，微软视窗就是一个很好的例子。另外还有XNU，运行在苹果Mac OS X上的内核，也是一个混合内核。
混合内核的例子：
1、BeOS 内核
2、DragonFly BSD
3、ReactOS 内核
Windows NT、Windows 2000、Windows XP、Windows Server 2003以及Windows Vista等基于NT技术的操作系统。XNU一些人认为可以在运行时加载模块的单核系统和混合内核系统没有区别。这是不正确的。混合意味着它从单核和微核系统中都吸取了一定的设计模式，例如一些非关键的代码在用户空间运行，另一些在内核空间运行，单纯是为了效率的原因。
外内核编辑本段回目录
 |
| 内核 |
Linux 排队自旋锁编辑本段回目录
 |
| 内核 |
自旋锁(Spinlock)是一种 Linux 内核中广泛运用的底层同步机制。自旋锁是一种工作于多处理器环境的特殊的锁，在单处理环境中自旋锁的操作被替换为空操作。当某个处理器上的内核执行线程申请自旋锁时，如果锁可用，则获得锁，然后执行临界区操作，最后释放锁；如果锁已被占用，线程并不会转入睡眠状态，而是忙等待该锁，一旦锁被释放，则第一个感知此信息的线程将获得锁。长期以来，人们总是关注于自旋锁的安全和高效，而忽视了自旋锁的“公平”性。传统的自旋锁本质上用一个整数来表示，值为1代表锁未被占用。这种无序竞争的本质特点导致执行线程无法保证何时能取到锁，某些线程可能需要等待很长时间。随着计算机处理器个数的不断增长，这种“不公平”问题将会日益严重。排队自旋锁(FIFO Ticket Spinlock)是 Linux 内核 2.6.25 版本引入的一种新型自旋锁，它通过保存执行线程申请锁的顺序信息解决了传统自旋锁的“不公平”问题。排队自旋锁的代码由 Linux 内核开发者 Nick Piggin 实现，目前只针对 x86 体系结构(包括 IA32 和 x86_64)，相信很快就会被移植到其它平台。
Linux 内核自旋锁的底层数据结构 raw_spinlock_t 定义如下：
|
typedef struct { |
slock 虽然被定义为无符号整数，但是实际上被当作有符号整数使用。slock 值为 1 代表锁未被占用，值为 0 或负数代表锁被占用。初始化时 slock 被置为 1。线程通过宏 spin_lock 申请自旋锁。如果不考虑内核抢占，则 spin_lock 调用 __raw_spin_lock 函数，代码如下所示：
清单 2. __raw_spin_lock 函数
|
static inline void __raw_spin_lock(raw_spinlock_t *lock) |
清单 3. LOCK_PREFIX宏
|
#ifdef CONFIG_SMP #else /* ! CONFIG_SMP */ |
在多处理器环境中 LOCK_PREFIX 实际被定义为 “lock”前缀。
linux内核文件的区别编辑本段回目录
 |
| 内核 |
zImage是vmlinux经过gzip压缩后的文件。
bzImage bz表示“big zImage”，不是用bzip2压缩的。两者的不同之处在于，zImage解压缩内核到低端内存(第一个640K)，bzImage解压缩内核到高端内存(1M以上)。如果内核比较小，那么采用zImage或bzImage都行，如果比较大应该用bzImage。
uImageU-boot专用的映像文件，它是在zImage之前加上一个长度为0x40的tag。
vmlinuz是bzImage/zImage文件的拷贝或指向bzImage/zImage的链接。
initrd是“initial ramdisk”的简写。一般被用来临时的引导硬件到实际内核vmlinuz能够接管并继续引导的状态。
发展改进编辑本段回目录
源代码管理
内核
历史上，从来没有出现过用于Linux内核的正式的源代码管理或修正控制系统。实际上，很多开发者实现了他们自己的修正控制器，但是并没有官方的LinuxCVS档案库，让LinusTorvalds检查加入代码，并让其他人可以由此获得代码。修正控制器的缺乏，常常会使发行版本之间存在“代沟”，没有人真正知道加入了哪些改变，这些改变是否能很好地融合，或者在即将发行的版本中哪些新内容是值得期待的。通常，如果更多的开发者可以像了解他们自己所做的改变一样了解到那些变化，某些问题就可以得到避免。由于缺乏正式的修正控制器和源代码管理工具，使得很多人提议使用一个名为BitKeeper的产品。BitKeeper是一个源代码控制管理系统，很多内核开发者已经成功地将其应用于他们自己的内核开发工作中。最初的2.5内核发布后不久，LinusTorvalds开始试用BitKeeper，以确定它是否能满足他的需要。现在，主要的2.4和2.5内核的Linux内核源代码都是用BitKeeper来管理的。对大部分可能很少或者根本不关心内核开发的用户来说，这一点看起来可能无关紧要。不过，在一些情况下，用户可以受益于那些由于使用BitKeeper而带来的开发Linux内核的方法的改变。
使用BitKeeper的最大好处之一是补丁的融合。当多个补丁应用于同一基础的代码之上，并且其中一些补丁会对同一部分产生影响时，就可能会出现融合问题。一个好的源代码管理系统可以自动地完成其中一些更为复杂的部分工作，这样可以更快地融合补丁，并使更多的补丁加入到内核中。随着Linux内核开发者社区的扩大，非常需要修正控制器来帮助保持对所有改变的追踪。由于每个人都可以将这些改变集成到主要的Linux内核中，为保证补丁不会被遗忘并可以方便地融合和管理，BitKeeper等工具是必不可少的。非常有必要使用一个实时的、集中的档案库来保存对Linux内核的最新更新。每一个被内核接受的改变或者补丁都被作为一个改变集被追踪。终端用户和开发者可以保存他们自己的源文件档案库，并根据需要可以通过一个简单的命令用最新的改变集进行更新。对开发者来说，这意味着可以始终使用最新的代码拷贝。测试人员可以使用这些逻辑的改变集合来确定哪些变化导致了问题的产生，缩短调试所需要的时间。甚至那些希望使用最新内核的用户也可以直接利用实时的、集中的档案库，因为现在一旦他们所需要的部件或缺陷修复加入到内核中，他们就可以马上进行更新。当代码融合到内核时，任何用户都可以提供关于这些代码的即时反馈和缺陷报告。
并行开发
内核
随着Linux内核的成长，变得更加复杂，而且吸引更多开发者将注意力集中到内核的特定方面的专门开发上来，出现了另一个开发Linux方法的有趣改变。在2.3内核版本的开发期间，除了由LinusTorvalds发行的主要的一个内核树之外，还有一些其他的内核树。在2.5的开发期间，内核树出现了爆炸式的增长。由于使用源代码管理工具可以保持开发的同步并行进行，这样就可能实现开发的部分并行化。为了让其他人在他们所做的改变被接受之前可以进行测试，有一些开发需要并行化。那些保持自己的树的内核维护者致力于特定的组件和目标，比如内存管理、NUMA部件、改进扩展性和用于特定体系结构的代码，还有一些树收集并追踪对许多小缺陷的纠正。
Linux2.5开发树
这种并行开发模型的优点是，它使得需要进行重大改变的开发者，或者针对一个特定的目标进行大量类似改变的那些开发者可以自由地在一个受控环境中开发，而并不影响其他人所用内核的稳定性。当开发者完成工作后，他们可以发布针对Linux内核当前版本的补丁，以实现到此为止他们所完成的改变。这样，社区中的测试人员就可以方便地测试这些改变并提供反馈。当每一部分都被证明是稳定的之后，那些部分可以单独地，或者甚至同时全部地，融合到主要Linux内核中。
在实际应用中测试
过去，Linux内核测试方法围绕开放源代码开发模型进行。由于代码一经发布后就公开给其他开发者进行审查，因此从来没有出现过一个与其他形式的软件开发类似的正式的验证周期。这种方法背后的理论依据是“TheCathedralandtheBazaar”中所谓的“Linus法则”，这一法则的内容为“众人的眼光是雪亮的”。换句话说，高力度的审查可以找出大部分真正的大问题。然而实际上，内核有很多复杂的相互联系。即使进行了足够力度的审查，还是会漏过很多严重的缺陷。此外，最新的内核一经发布，终端用户可以下载并使用。2.4.0发布时，社区中很多人都提议进行更有组织的测试，以保证特定测试和代码审查的强度。有组织的测试包括运用测试计划、测试过程中的可重复性等等。使用所有的三种方法比最初只使用两种方法会带来更高的代码质量。
Linux测试项目
内核
最早对Linux开始进行有组织测试的贡献者是Linux测试项目(LinuxTestProject，LTP)。这个项目的目的是通过更有组织的测试方法提高Linux的质量。这个测试项目的一部分是自动测试套件的开发。LTP开发的主要测试套件也叫做Linux测试项目。2.4.0内核发布时，LTP测试套件只有大约100个测试。随着2.4和2.5版本Linux的发展与成熟，LTP测试套件也正在发展和成熟。当前，Linux测试项目包括超过2000个测试，而且这个数字还在增长!
代码覆盖分析
现在所使用的新工具为内核提供了代码覆盖分析的功能。覆盖分析告诉我们，在一个给定的测试运行时，内核中哪些行代码被执行。更重要的是，覆盖分析提示了内核的哪些部分还根本没有被测试到。这个数据是重要的，因为它指出了需要再编写哪些新测试来测试内核的那些部分，以使内核可以得到更完备的测试。
持续多日的内核回归测试
在2.5的开发周期中，Linux测试项目所采用的另一个项目是，用LTP测试套件对Linux内核执行持续多日的回归测试。人们用BitKeeper创建了一个实时的、集中的档案库，以随时可以获得Linux内核的快照。在没有使用BitKeeper和快照时，测试人员不得不等到内核发布后才可以开始测试。现在，内核只要发生了改变，测试人员就可以进行测试。使用自动化工具来执行持续多日的回归测试的另一个优点是，和上一次测试相比变化较小。如果发现了一个新的回归缺陷，通常会容易地检测出这个缺陷可能是哪个改变导致的。同样，由于是最新的改变，因此它在开发者的脑海中印象还比较深——希望这能让他们更容易地记起并修订相应的代码。或许Linus法则应该有这样一个结论，有一些缺陷比其他缺陷更容易被发现，因为那些正是持续多日的内核回归测试所发现并处理的那些。在开发周期中和实际发布之前能够每天进行这些测试，这就使那些只关注完整发行版本的测试者可以将精力集中于更严重和耗时的缺陷。
可扩展测试平台
内核
另外一个名为开放源代码开发实验室(OpenSourceDevelopmentLabs,OSDL)的团队也为Linux测试做出了重要的贡献。2.4内核发布后不久，OSDL创建了一个叫做可扩展测试平台(ScalableTestPlatform，STP)的系统。STP是一个自动化的测试平台，让开发者和测试者可以运行OSDL硬件之上的系统所提供的测试。开发者甚至可以使用这个系统来测试他们自己的针对内核的补丁。可扩展测试平台简化了测试的步骤，因为STP可以构建内核、设置测试、运行测试，并收集结果。然后得到结果以进行深入地比较。很多人无法接触大型系统，比如具有8个处理器的SMP机器，而通过STP，任何人都可以在像这样的大型系统上运行测试，这个系统(STP)的另一个好处就在于此。
追踪缺陷
自从2.4发布以来，对Linux内核的有组织测试最大的改进之一是缺陷追踪。过去，在Linux内核中发现的缺陷会报告给Linux内核邮件列表，报告给特定组件或者特定体系的邮件列表，或者直接报告给维护发现缺陷的那部分代码的个人。随着开发和测试Linux的人数的增加，这个系统的不足之处很快就暴露了出来。在以前，除非人们对缺陷的报告可以惊人地维持下去，缺陷经常被遗漏、遗忘或者忽略。现在，OSDL安装了一个缺陷追踪系统（请参阅参考资料中的链接），来报告和追踪Linux内核的缺陷。系统经过了配置，这样当某个组件的缺陷被报告时，那个组件的维护者就会得到通知。维护者既可以接受并修复那个缺陷，或重新指定缺陷（如果最终确定实际上那是内核另外一部分的缺陷），也可以排除它（如果最终确定并不是真正的缺陷，比如错误配置的系统）。报告给邮件列表的缺陷还有丢失的危险，因为越来越多的电子邮件涌向那个列表。然而，在缺陷追踪系统中，始终有对每一个缺陷及其当前状态的记录。
大量信息
在为将来的2.6Linux内核进行开的过程中，除了这些自动化的信息管理方法之外，开放源代码社区的不同成员还收集和追踪了数量惊人的信息。例如，在KernelNewbies站点上创建了一个状态列表，来保持对已经提出的内核新部件的追踪。这个列表包含了以状态排序的条目，如果它们已经完成了，则说明它们已经包含在哪个内核中，如果还没有完成，则指出还需要多长时间。列表上很多条目的链接指向大型项目的Web站点，或者当条目较小时，链接指向一个解释相应部件的电子邮件信息的拷贝。
版本历史编辑本段回目录
 |
| 内核 |
大约从这时起开始使用两“路”编号方法标注内核的开发。偶数号的内核（比如1.0、2.2、2.4，现在是2.6）是稳定的，“产品”型号。同时，奇数号的内核版本（1.1、2.3）是前沿的或者“发展中的”内核。直接最近，一个稳定的内核发布以后几个月就开始新内核的开发工作。然而，2.5的开发工作是在2.4完成后几个月以后才开始的。“post-halloween文档”告诉用户即将到来的2.6内核有哪些可期待的东西。post-halloween文档的大部分讨论内容是用户需要注意的主要改变，以及需要更新的系统工具。关心这一信息人的主要是那些期望提前了解2.6内核中有哪些内容的Linux发行商，还有终端用户，这可以让他们确定为了能利用新部件是否有需要升级的程序。
KernelJanitors项目保持了（实际上现在还在保持）一个列表，内容是需要修复的较小缺陷和解决方法。这些缺陷解决方法中大部分是由于向内核打较大的补丁时需要改动很多部分代码而导致的，比如有些地方会影响设备驱动程序。那些新近从事内核开发的人开始时的工作可以选择列表中的条目，这样让他们可以通过小项目学习如何编写内核代码，同时有机会为社区做出贡献。还有，在另一个预发布的项目中，JohnCherry追踪了在对每个已经发布的内核版本进行编译时发现的错误和警告。这些编译统计数字随着时间的流逝一直持续下降，而且，以系统的
 |
| 内核 |
2.6内核发布以后，这些资料中有一些已经明显不再进行维护了。其他的相关工作在主要版本发布后仍未结束，还要继续进行后期的更新。有趣的是能看到哪些又被重新提起，有了哪些革新，我们又一次接近了一个主要发布版本。多数人在考虑内核的一个新的稳定版本时，第一个问题通常是“这一版本中有什么新东西吗？”实际上除了一些新特性和修复之外，在幕后还有一个随着时间而不断改进的过程。在Linux社区中，开放源代码开发日益兴旺。致力于Linux内核和其他方面工作的编码者之间联系是松散的，这就使得团队可以成功地适应变化。在许多方面，相对于已经完成的很多单个的改进和缺陷修复而言，Linux的开发和测试方法——尤其是这些方法随时间的推移得到了改进——对新内核的可靠性影响更为深远。
