内核是操作系统最基本的部分。它是为众多应用程序提供对计算机硬件的安全访问的一部分软件，这种访问是有限的，并且内核决定一个程序在什么时候对某部分硬件操作多长时间。内核的分类可分为单内核和双内核以及微内核。
内核是操作系统最基本的部分。它是为众多应用程序提供对计算机硬件的安全访问的一部分软件，这种访问是有限的，并且内核决定一个程序在什么时候对某部分硬件操作多长时间。内核的分类可分为单内核和双内核以及微内核。严格地说，内核并不是计算机系统中必要的组成部分。
内核，是一个操作系统的核心。是基于硬件的第一层软件扩充，提供操作系统的最基本的功能，是操作系统工作的基础，它负责管理系统的进程、内存、设备驱动程序、文件和网络系统，决定着系统的性能和稳定性。
现代操作系统设计中，为减少系统本身的开销，往往将一些与硬件紧密相关的（如中断处理程序、设备驱动程序等）、基本的、公共的、运行频率较高的模块（如时钟管理、进程调度等）以及关键性数据结构独立开来，使之常驻内存，并对他们进行保护。通常把这一部分称之为操作系统的内核。
程序可以直接地被调入计算机中执行，这样的设计说明了设计者不希望提供任何硬件抽象和操作系统的支持，它常见于早期计算机系统的设计中。最终，一些辅助性程序，例如程序加载器和调试器，被设计到机器核心当中，或者固化在只读存储器里。这些变化发生时，操作系统内核的概念就渐渐明晰起来了。
Linux 的第一个公开版本是 1991 年 10 月的 0.02 版本，两个月以后，在 1991 年 12 月，Linux 发布了 0.11 版本，这是第一个可以不依赖于 Minix 就可以使用的独立内核。
0.12 版本发布一个月以后，在 3 月，版本号跳到了 0.95，反映出系统正变得成熟，不仅如此，直到两年后，也就是 1994 年 3 月，具有里程碑意义的 1.0.0 才完成。
大约从这时起开始使用两“路”编号方法标注内核的开发，偶数号的内核（比如 1.0、2.2、2.4、2.6）是稳定的，“产品”型号，同时，奇数号的内核版本（1.1、2.3）是前沿的或者“发展中的”内核。一个稳定的内核发布以后几个月就开始新内核的开发工作。然而，2.5 的开发工作是在 2.4 完成后几十个月以后才开始的。
post-halloween 文档的大部分讨论内容是用户需要注意的主要改变，以及需要更新的系统工具（为了利用它们）。关心这一信息人的主要是那些期望提前了解 2.6 内核中有哪些内容的 Linux 发行商，还有终端用户，这可以让他们确定为了能利用新部件是否有需要升级的程序。
KernelJanitors 项目保持了一个列表，内容是需要修复的较小缺陷和解决方法。这些缺陷解决方法中大部分是由于向内核打较大的补丁时需要改动很多部分代码而导致的，比如有些地方会影响设备驱动程序。那些新近从事内核开发的人开始时的工作可以选择列表中的条目，这样让他们可以通过小项目学习如何编写内核代码，同时有机会为社区做出贡献。
还有，在另一个预发布的项目中，JohnCherry 追踪了在对每个已经发布的内核版本进行编译时发现的错误和警告。这些编译统计数字随着时间的流逝一直持续下降，而且，以系统的形式来发布这些结果使得所取得的进展一目了然。在很多情况下，可以像使用 KernelJanitors 列表一样来利用这些警告和错误消息中的一部分，因为编译错误通常是由小的缺陷引起的，需要一些努力去修复。
最后，还有 AndrewMorton 的“must-fix”列表。由于他已经被选定为 2.6 内核发布后的维护者，他运用他的特权概括地列出了那些他认为在最终的 2.6 内核发布前最迫切需要解决方案的问题。must-fix 列表中包含了内核 Bugzilla 系统中的缺陷，需要完成的部件，以及其他已知的问题，这些问题如不解决将阻碍 2.6 发布。这一信息可以帮助指明在新内核发布前还需要哪些步骤；对那些关心这一万众期待的 2.6 内核发布何时能完成的人来说，它还可以提供有价值的信息。
单内核（Monolithic kernel），是个很大的进程。它的内部又能够被分为若干模块（或是层次或其他）。但是在运行的时候，它是个单独的二进制大映象。其模块间的通讯是通过直接调用其他模块中的函数实现的，而不是消息传递。
单内核结构在硬件之上定义了一个高阶的抽象界面，应用一组原语(或者叫系统调用)来实现操作系统的功能，例如进程管理，文件系统，和存储管理等等，这些功能由多个运行在核心态的模块来完成。
尽管每一个模块都是单独地服务这些操作，内核代码是高度集成的，而且难以编写正确。因为所有的模块都在同一个内核空间上运行，一个很小的 bug 都会使整个系统崩溃。然而，如果开发顺利，单内核结构就可以从运行效率上得到好处。
很多现代的单内核结构内核，如 Linux 和 FreeBSD 内核，能够在运行时将模块调入执行，这就可以使扩充内核的功能变得更简单，也可以使内核的核心部分变得更简洁。
单内核结构是非常有吸引力的一种设计，由于在同一个地址空间上实现所有低级操作的系统控制代码的复杂性的效率会比在不同地址空间上实现更高些。 单核结构正趋向于容易被正确设计，所以它的发展会比微内核结构更迅速些。
单内核结构的例子：传统的 UNIX 内核—-例如伯克利大学发行的版本，Linux 内核。
内核提供一种硬件抽象的方法来完成对硬件操作，因为这些操作是非常复杂的，硬件抽象隐藏了复杂性，为应用软件和硬件提供了一套简洁，统一的接口，使程序设计更为简单。
历史上，从来没有出现过用于 Linux 内核的正式的源代码管理或修正控制系统。实际上，很多开发者实现了他们自己的修正控制器，但是并没有官方的 LinuxCVS 档案库，让 LinusTorvalds 检查加入代码，并让其他人可以由此获得代码。修正控制器的缺乏，常常会使发行版本之间存在“代沟”，没有人真正知道加入了哪些改变，这些改变是否能很好地融合，或者在即将发行的版本中哪些新内容是值得期待的。通常，如果更多的开发者可以像了解他们自己所做的改变一样了解到那些变化，某些问题就可以得到避免。
非常有必要使用一个实时的、集中的档案库来保存对 Linux 内核的最新更新。每一个被内核接受的改变或者补丁都被作为一个改变集被追踪。终端用户和开发者可以保存他们自己的源文件档案库，并根据需要可以通过一个简单的命令用最新的改变集进行更新。对开发者来说，这意味着可以始终使用最新的代码拷贝。测试人员可以使用这些逻辑的改变集合来确定哪些变化导致了问题的产生，缩短调试所需要的时间。甚至那些希望使用最新内核的用户也可以直接利用实时的、集中的档案库，因为一旦他们所需要的部件或缺陷修复加入到内核中，他们就可以马上进行更新。当代码融合到内核时，任何用户都可以提供关于这些代码的即时反馈和缺陷报告。
测试背景
过去，Linux 内核测试方法围绕开放源代码开发模型进行。由于代码一经发布后就公开给其他开发者进行审查，因此从来没有出现过一个与其他形式的软件开发类似的正式的验证周期。这种方法背后的理论依据是“TheCathedralandtheBazaar”中所谓的“Linus 法则”（请查阅参考资料以获得相关的参考），这一法则的内容为“众人的眼光是雪亮的”。换句话说，高力度的审查可以找出大部分真正的大问题。
然而实际上，内核有很多复杂的相互联系。即使进行了足够力度的审查，还是会漏过很多严重的缺陷。此外，最新的内核一经发布，终端用户可以（也经常是）下载并使用。2.4.0 发布时，社区中很多人都提议进行更有组织的测试，以保证特定测试和代码审查的强度。有组织的测试包括运用测试计划、测试过程中的可重复性等等。使用所有的三种方法比最初只使用两种方法会带来更高的代码质量。
测试项目
最早对 Linux 开始进行有组织测试的贡献者是 Linux 测试项目(LinuxTestProject，LTP)。这个项目的目的是通过更有组织的测试方法提高 Linux 的质量。这个测试项目的一部分是自动测试套件的开发。LTP 开发的主要测试套件也叫做 Linux 测试项目。2.4.0 内核发布时，LTP 测试套件只有大约 100 个测试。随着 2.4 和 2.5 版本 Linux 的发展与成熟，LTP 测试套件也正在发展和成熟。当前，Linux 测试项目包括超过 2000 个测试，而且这个数字还在增长。
微信公众号