|
|
|
Weather
Category
HotArticle
NewReply
Links
Statistics
 Articles:383
Replies:22
View:116470
|
以文件example.c为例说明它的用法 1. arm-linux-gcc -c -o example.o example.c 2.arm-linux-gcc -S -o example.s example.c 3.arm-linux-gcc -E -o example.i example.c 5.arm-linux-gcc -g -o example example.c 6.arm-linux-gcc -Wall -o example example.c 7.arm-linux-gcc -Ox -o example example.c 8.arm-linux-gcc -I /home/include -o example example.c 9.arm-linux-gcc -L /home/lib -o example example.c -Ldirname：将dirname所指出的目录加入到库文件的目录列表中。在默认状态下，连接程序ld在系统的预设路径中(如/usr/lib)寻找所需要的库文件，这个选项告诉连接程序，首先到-L指定的目录中去寻找，然后再到系统预设路径中寻找。 10.arm-linux-gcc –static -o libexample.a example.c 静态链接库文件 gcc在命令行上经常使用的几个选项是：
早期时，启动一台计算机意味着要给计算机喂一条包含引导程序的纸带，或者手工使用前端面板地址/数据/控制开关来加载引导程序。尽管目前的计算机已经装备了很多工具来简化引导过程，但是这一切并没有对整个过程进行必要的简化。 让我们先从高级的视角来查看 Linux 引导过程，这样就可以看到整个过程的全貌了。然后将回顾一下在各个步骤到底发生了什么。在整个过程中，参考一下内核源代码可以帮助我们更好地了解内核源代码树，并在以后对其进行深入分析。 图 1 是我们在 20,000 英尺的高度看到的视图。 当系统首次引导时，或系统被重置时，处理器会执行一个位于已知位置处的代码。在个人计算机（PC）中，这个位置在基本输入/输出系统（BIOS）中，它保存在主板上的闪存中。嵌入式系统中的中央处理单元（CPU）会调用这个重置向量来启动一个位于闪存/ROM 中的已知地址处的程序。在这两种情况下，结果都是相同的。因为 PC 提供了很多灵活性，BIOS 必须确定要使用哪个设备来引导系统。稍后我们将详细介绍这个过程。 当找到一个引导设备之后，第一阶段的引导加载程序就被装入 RAM 并执行。这个引导加载程序在大小上小于 512 字节（一个扇区），其作用是加载第二阶段的引导加载程序。 当第二阶段的引导加载程序被装入 RAM 并执行时，通常会显示一个动画屏幕，并将 Linux 和一个可选的初始 RAM 磁盘（临时根文件系统）加载到内存中。在加载映像时，第二阶段的引导加载程序就会将控制权交给内核映像，然后内核就可以进行解压和初始化了。在这个阶段中，第二阶段的引导加载程序会检测系统硬件、枚举系统链接的硬件设备、挂载根设备，然后加载必要的内核模块。完成这些操作之后启动第一个用户空间程序（ 这就是 Linux 引导的整个过程。现在让我们深入挖掘一下这个过程，并深入研究一下 Linux 引导过程的一些详细信息。 系统启动阶段依赖于引导 Linux 系统上的硬件。在嵌入式平台中，当系统加电或重置时，会使用一个启动环境。这方面的例子包括 U-Boot、RedBoot 和 Lucent 的 MicroMonitor。嵌入式平台通常都是与引导监视器搭配销售的。这些程序位于目标硬件上的闪存中的某一段特殊区域，它们提供了将 Linux 内核映像下载到闪存并继续执行的方法。除了可以存储并引导 Linux 映像之外，这些引导监视器还执行一定级别的系统测试和硬件初始化过程。在嵌入式平台中，这些引导监视器通常会涉及第一阶段和第二阶段的引导加载程序。 在 PC 中，引导 Linux 是从 BIOS 中的地址 0xFFFF0 处开始的。BIOS 的第一个步骤是加电自检（POST）。POST 的工作是对硬件进行检测。BIOS 的第二个步骤是进行本地设备的枚举和初始化。 给定 BIOS 功能的不同用法之后，BIOS 由两部分组成：POST 代码和运行时服务。当 POST 完成之后，它被从内存中清理了出来，但是 BIOS 运行时服务依然保留在内存中，目标操作系统可以使用这些服务。 要引导一个操作系统，BIOS 运行时会按照 CMOS 的设置定义的顺序来搜索处于活动状态并且可以引导的设备。引导设备可以是软盘、CD-ROM、硬盘上的某个分区、网络上的某个设备，甚至是 USB 闪存。 通常，Linux 都是从硬盘上引导的，其中主引导记录（MBR）中包含主引导加载程序。MBR 是一个 512 字节大小的扇区，位于磁盘上的第一个扇区中（0 道 0 柱面 1 扇区）。当 MBR 被加载到 RAM 中之后，BIOS 就会将控制权交给 MBR。 MBR 中的主引导加载程序是一个 512 字节大小的映像，其中包含程序代码和一个小分区表（参见图 2）。前 446 个字节是主引导加载程序，其中包含可执行代码和错误消息文本。接下来的 64 个字节是分区表，其中包含 4 个分区的记录（每个记录的大小是 16 个字节）。MBR 以两个特殊数字的字节（0xAA55）结束。这个数字会用来进行 MBR 的有效性检查。 主引导加载程序的工作是查找并加载次引导加载程序（第二阶段）。它是通过在分区表中查找一个活动分区来实现这种功能的。当找到一个活动分区时，它会扫描分区表中的其他分区，以确保它们都不是活动的。当这个过程验证完成之后，就将活动分区的引导记录从这个设备中读入 RAM 中并执行它。 次引导加载程序（第二阶段引导加载程序）可以更形象地称为内核加载程序。这个阶段的任务是加载 Linux 内核和可选的初始 RAM 磁盘。 在 x86 PC 环境中，第一阶段和第二阶段的引导加载程序一起称为 Linux Loader（LILO）或 GRand Unified Bootloader（GRUB）。由于 LILO 有一些缺点，而 GRUB 克服了这些缺点，因此下面让我们就来看一下 GRUB。（有关 GRUB、LILO 和相关主题的更多内容，请参阅本文后面的 参考资料 部分的内容。） 关于 GRUB，很好的一件事情是它包含了有关 Linux 文件系统的知识。GRUB 不像 LILO 一样使用裸扇区，而是可以从 ext2 或 ext3 文件系统中加载 Linux 内核。它是通过将两阶段的引导加载程序转换成三阶段的引导加载程序来实现这项功能的。阶段 1 （MBR）引导了一个阶段 1.5 的引导加载程序，它可以理解包含 Linux 内核映像的特殊文件系统。这方面的例子包括 当阶段 2 加载之后，GRUB 就可以在请求时显示可用内核列表（在 将第二阶段的引导加载程序加载到内存中之后，就可以对文件系统进行查询了，并将默认的内核映像和 当内核映像被加载到内存中，并且阶段 2 的引导加载程序释放控制权之后，内核阶段就开始了。内核映像并不是一个可执行的内核，而是一个压缩过的内核映像。通常它是一个 zImage（压缩映像，小于 512KB）或一个 bzImage（较大的压缩映像，大于 512KB），它是提前使用 zlib 进行压缩过的。在这个内核映像前面是一个例程，它实现少量硬件设置，并对内核映像中包含的内核进行解压，然后将其放入高端内存中，如果有初始 RAM 磁盘映像，就会将它移动到内存中，并标明以后使用。然后该例程会调用内核，并开始启动内核引导的过程。 当 bzImage（用于 i386 映像）被调用时，我们从 在这个新的 通过调用 在内核引导过程中，初始 RAM 磁盘（ 当内核被引导并进行初始化之后，内核就可以启动自己的第一个用户空间应用程序了。这是第一个调用的使用标准 C 库编译的程序。在此之前，还没有执行任何标准的 C 应用程序。 在桌面 Linux 系统上，第一个启动的程序通常是 与 Linux 本身非常类似，Linux 的引导过程也非常灵活，可以支持众多的处理器和硬件平台。最初，加载引导加载程序提供了一种简单的方法，不用任何花架子就可以引导 Linux。LILO 引导加载程序对引导能力进行了扩充，但是它却缺少文件系统的感知能力。最新一代的引导加载程序，例如 GRUB，允许 Linux 从一些文件系统（从 Minix 到 Reise）上进行引导。 学习 获得产品和技术 讨论
本文将回顾一下 Linux 2.6 的任务调度器及其最重要的一些属性。在深入介绍调度器的详细信息之前，让我们先来理解一下调度器的基本目标。 通常来说，操作系统是应用程序和可用资源之间的媒介。典型的资源有内存和物理设备。但是 CPU 也可以认为是一个资源，调度器可以临时分配一个任务在上面执行（单位是时间片）。调度器使得我们同时执行多个程序成为可能，因此可以与具有各种需求的用户共享 CPU。 调度器的一个重要目标是有效地分配 CPU 时间片，同时提供很好的用户体验。调度器还需要面对一些互相冲突的目标，例如既要为关键实时任务最小化响应时间，又要最大限度地提高 CPU 的总体利用率。下面我们来看一下 Linux 2.6 调度程序是如何实现这些目标的，并与以前的调度器进行比较。 在 2.6 版本的内核之前，当很多任务都处于活动状态时，调度器有很明显的限制。这是由于调度器是使用一个复杂度为 O(n) 的算法实现的。在这种调度器中，调度任务所花费的时间是一个系统中任务个数的函数。换而言之，活动的任务越多，调度任务所花费的时间越长。在任务负载非常重时，处理器会因调度消耗掉大量的时间，用于任务本身的时间就非常少了。因此，这个算法缺乏可伸缩性。 在对称多处理系统（SMP）中，2.6 版本之前的调度器对所有的处理器都使用一个运行队列。这意味着一个任务可以在任何处理器上进行调度 —— 这对于负载均衡来说是好事，但是对于内存缓存来说却是个灾难。例如，假设一个任务正在 CPU-1 上执行，其数据在这个处理器的缓存中。如果这个任务被调度到 CPU-2 上执行，那么数据就需要先在 CPU-1 使其无效，并将其放到 CPU-2 的缓存中。 以前的调度器还使用了一个运行队列锁；因此在 SMP 系统中，选择一个任务执行就会阻碍其他处理器操作这个运行队列。结果是空闲处理器只能等待这个处理器释放出运行队列锁，这样会造成效率的降低。 最后，在早期的内核中，抢占是不可能的；这意味着如果有一个低优先级的任务在执行，高优先级的任务只能等待它完成。 2.6 版本的调度器是由 Ingo Molnar 设计并实现的。Ingo 从 1995 年开始就一直参与 Linux 内核的开发。他编写这个新调度器的动机是为唤醒、上下文切换和定时器中断开销建立一个完全 O(1) 的调度器。触发对新调度器的需求的一个问题是 Java™ 虚拟机（JVM）的使用。Java 编程模型使用了很多执行线程，在 O(n) 调度器中这会产生很多调度负载。O(1) 调度器在这种高负载的情况下并不会受到太多影响，因此 JVM 可以有效地执行。 2.6 版本的调度器解决了以前调度器中发现的 3 个主要问题（O(n) 和 SMP 可伸缩性的问题），还解决了其他一些问题。现在我们将开始探索一下 2.6 版本的调度器的基本设计。 首先我们来回顾一下 2.6 版本的调度器结构。每个 CPU 都有一个运行队列，其中包含了 140 个优先级列表，它们是按照先进先出的顺序进行服务的。被调度执行的任务都会被添加到各自运行队列优先级列表的末尾。每个任务都有一个时间片，这取决于系统允许执行这个任务多长时间。运行队列的前 100 个优先级列表保留给实时任务使用，后 40 个用于用户任务（参见图 1）。我们稍后将来看一下为什么这种区别非常重要。 除了 CPU 的运行队列（称为活动运行队列（active runqueue））之外，还有一个过期运行队列。当活动运行队列中的一个任务用光自己的时间片之后，它就被移动到过期运行队列（expired runqueue） 中。在移动过程中，会对其时间片重新进行计算（因此会体现其优先级的作用；稍后会更详细地介绍）。如果活动运行队列中已经没有某个给定优先级的任务了，那么指向活动运行队列和过期运行队列的指针就会交换，这样就可以让过期优先级列表变成活动优先级的列表。 调度器的工作非常简单：它在优先级最高的队列中选择一个任务来执行。为了使这个过程的效率更高，内核使用了一个位图来定义给定优先级列表上何时存在任务。因此，在大部分体系架构上，会使用一条 那么什么是 SMP 呢？SMP 是一种体系架构，其中多个 CPU 可以用来同时执行各个任务，它与传统的非对称处理系统不同，后者使用一个 CPU 来执行所有的任务。SMP 体系架构对多线程的应用程序非常有益。 尽管优先级调度在 SMP 系统上也可以工作，但是它这种大锁体系架构意味着当一个 CPU 选择一个任务进行分发调度时，运行队列会被这个 CPU 加锁，其他 CPU 只能等待。2.6 版本的调度器不是使用一个锁进行调度；相反，它对每个运行队列都有一个锁。这样允许所有的 CPU 都可以对任务进行调度，而不会与其他 CPU 产生竞争。 另外，由于每个处理器都有一个运行队列，因此任务通常都是与 CPU 密切相关的，可以更好地利用 CPU 的热缓存。 Linux 2.6 版本调度器的另外一个优点是它允许抢占。这意味着当高优先级的任务准备运行时低优先级的任务就不能执行了。调度器会抢占低优先级的进程，并将这个进程放回其优先级列表中，然后重新进行调度。 似乎 2.6 版本调度器的 O(1) 特性和抢占特性还不够，这个调度器还提供了动态任务优先级和 SMP 负载均衡功能。下面就让我们来讨论一下这些功能都是什么，以及它们分别提供了哪些优点。 为了防止任务独占 CPU 从而会饿死其他需要访问 CPU 的任务，Linux 2.6 版本的调度器可以动态修改任务的优先级。这是通过惩罚 CPU 绑定的任务而奖励 I/O 绑定的任务实现的。I/O 绑定的任务通常使用 CPU 来设置 I/O，然后就睡眠等待 I/O 操作完成。这种行为为其他任务提供了 CPU 的访问能力。 由于 I/O 绑定型的任务对于 CPU 访问来说是无私的，因此其优先级减少（奖励）最多 5 个优先级。CPU 绑定的任务会通过将其优先级增加最多 5 个优先级进行惩罚。 任务到底是 I/O 绑定的还是 CPU 绑定的，这是根据交互性 原则确定的。任务的交互性指标是根据任务执行所花费的时间与睡眠所花费的时间的对比程度进行计算的。注意，由于 I/O 任务先对 I/O 进行调度，然后再进行睡眠，因此 I/O 绑定的任务会在睡眠和等待 I/O 操作完成上面花费更多的时间。这会提高其交互性指标。 有一点值得注意，优先级的调整只会对用户任务进行，对于实时任务来说并不会对其优先级进行调整。 在 SMP 系统中创建任务时，这些任务都被放到一个给定的 CPU 运行队列中。通常来说，我们无法知道一个任务何时是短期存在的，何时需要长期运行。因此，最初任务到 CPU 的分配可能并不理想。 为了在 CPU 之间维护任务负载的均衡，任务可以重新进行分发：将任务从负载重的 CPU 上移动到负载轻的 CPU 上。Linux 2.6 版本的调度器使用负载均衡（load balancing） 提供了这种功能。每隔 200ms，处理器都会检查 CPU 的负载是否不均衡；如果不均衡，处理器就会在 CPU 之间进行一次任务均衡操作。 这个过程的一点负面影响是新 CPU 的缓存对于迁移过来的任务来说是冷的（需要将数据读入缓存中）。 记住 CPU 缓存是一个本地（片上）内存，提供了比系统内存更快的访问能力。如果一个任务是在某个 CPU 上执行的，与这个任务有关的数据都会被放到这个 CPU 的本地缓存中，这就称为热的。如果对于某个任务来说，CPU 的本地缓存中没有任何数据，那么这个缓存就称为冷的。 不幸的是，保持 CPU 繁忙会出现 CPU 缓存对于迁移过来的任务为冷的情况。 2.6 版本调度器的源代码都很好地封装到了 /usr/src/linux/kernel/sched.c 文件中。我们在表 1 中对在这个文件中可以找到的一些有用的函数进行了总结。
运行队列的结构也可以在 /usr/src/linux/kernel/sched.c 文件中找到。2.6 版本的调度器还可以提供一些统计信息（如果启用了 Linux 2.6 调度器从早先的 Linux 调度器已经跨越了一大步。它极大地改善了最大化利用 CPU 的能力，同时还为用户提供了很好的响应体验。抢占和对多处理器体系架构的更好支持使整个系统更接近于多桌面和实时系统都非常有用的操作系统。Linux 2.8 版本的内核现在谈论还为时尚早，但是从 2.6 版本的变化中，我们可以期望会有更多的好东西。 学习 获得产品和技术 讨论 Tim Jones 是一名嵌入式软件工程师，他是 GNU/Linux Application Programming、AI Application Programming 以及 BSD Sockets Programming from a Multilanguage Perspective 等书的作者。他的工程背景非常广泛，从同步宇宙飞船的内核开发到嵌入式架构设计，再到网络协议的开发。Tim 是 Emulex Corp. 的一名顾问工程师。
最初开发 /proc 文件系统是为了提供有关系统中进程的信息。但是由于这个文件系统非常有用，因此内核中的很多元素也开始使用它来报告信息，或启用动态运行时配置。 /proc 文件系统包含了一些目录（用作组织信息的方式）和虚拟文件。虚拟文件可以向用户呈现内核中的一些信息，也可以用作一种从用户空间向内核发送信息的手段。实际上我们并不会同时需要实现这两点，但是本文将向您展示如何配置这个文件系统进行输入和输出。 尽管像本文这样短小的一篇文章无法详细介绍 /proc 的所有用法，但是它依然对这两种用法进行了展示，从而可以让我们体会一下 /proc 是多么强大。清单 1 是对 /proc 中部分元素进行一次交互查询的结果。它显示的是 /proc 文件系统的根目录中的内容。注意，在左边是一系列数字编号的文件。每个实际上都是一个目录，表示系统中的一个进程。由于在 GNU/Linux 中创建的第一个进程是 /proc 中另外一些有趣的文件有：
清单 2 展示了对 /proc 中的一个虚拟文件进行读写的过程。这个例子首先检查内核的 TCP/IP 栈中的 IP 转发的目前设置，然后再启用这种功能。
另外，我们还可以使用 顺便说一下，/proc 文件系统并不是 GNU/Linux 系统中的惟一一个虚拟文件系统。在这种系统上，sysfs 是一个与 /proc 类似的文件系统，但是它的组织更好（从 /proc 中学习了很多教训）。不过 /proc 已经确立了自己的地位，因此即使 sysfs 与 /proc 相比有一些优点，/proc 也依然会存在。还有一个 debugfs 文件系统，不过（顾名思义）它提供的更多是调试接口。debugfs 的一个优点是它将一个值导出给用户空间非常简单（实际上这不过是一个调用而已）。 可加载内核模块（LKM）是用来展示 /proc 文件系统的一种简单方法，这是因为这是一种用来动态地向 Linux 内核添加或删除代码的新方法。LKM 也是 Linux 内核中为设备驱动程序和文件系统使用的一种流行机制。 如果您曾经重新编译过 Linux 内核，就可能会发现在内核的配置过程中，有很多设备驱动程序和其他内核元素都被编译成了模块。如果一个驱动程序被直接编译到了内核中，那么即使这个驱动程序没有运行，它的代码和静态数据也会占据一部分空间。但是如果这个驱动程序被编译成一个模块，就只有在需要内存并将其加载到内核时才会真正占用内存空间。有趣的是，对于 LKM 来说，我们不会注意到有什么性能方面的差异，因此这对于创建一个适应于自己环境的内核来说是一种功能强大的手段，这样可以根据可用硬件和连接的设备来加载对应的模块。 下面是一个简单的 LKM，可以帮助您理解它与在 Linux 内核中看到的标准（非动态可加载的）代码之间的区别。清单 3 给出了一个最简单的 LKM。（可以从本文的 下载 一节中下载这个代码）。 清单 3 包括了必须的模块头（它定义了模块的 API、类型和宏）。然后使用 清单 3 然后又定义了这个模块的 最后，清单 3 使用
清单 3 尽管非常简单，但它却是一个真正的 LKM。现在让我们对其进行编译并在一个 2.6 版本的内核上进行测试。2.6 版本的内核为内核模块的编译引入了一种新方法，我发现这种方法比原来的方法简单了很多。对于文件
要编译 LKM，请使用
结果会生成一个
注意，内核的输出进到了内核回环缓冲区中，而不是打印到
可以在内核输出中看到这个模块的消息。现在让我们暂时离开这个简单的例子，来看几个可以用来开发有用 LKM 的内核 API。 内核程序员可以使用的标准 API，LKM 程序员也可以使用。LKM 甚至可以导出内核使用的新变量和函数。有关 API 的完整介绍已经超出了本文的范围，因此我们在这里只是简单地介绍后面在展示一个更有用的 LKM 时所使用的几个元素。 要在 /proc 文件系统中创建一个虚拟文件，请使用
稍后我们就可以看到如何使用 要从 /proc 中删除一个文件，可以使用 parent 参数可以为 NULL（表示 /proc 根目录），也可以是很多其他值，这取决于我们希望将这个文件放到什么地方。表 1 列出了可以使用的其他一些父
我们可以使用
Linux 提供了一组 API 来在用户空间和内核空间之间移动数据。对于 我们可以使用
我们还可以使用
下面是一个可以支持读写的 LKM。这个简单的程序提供了一个财富甜点分发。在加载这个模块之后，用户就可以使用 清单 9 给出了基本的模块函数和变量。
向这个罐中新写入一个 cookie 非常简单（如清单 10 所示）。使用这个写入 cookie 的长度，我们可以检查是否有这么多空间可用。如果没有，就返回
对 fortune 进行读取也非常简单，如清单 11 所示。由于我们刚才写入数据的缓冲区（
从这个简单的例子中，我们可以看出通过 /proc 文件系统与内核进行通信实际上是件非常简单的事情。现在让我们来看一下这个 fortune 模块的用法（参见清单 12）。
/proc 虚拟文件系统可以广泛地用来报告内核的信息，也可以用来进行动态配置。我们会发现它对于驱动程序和模块编程来说都是非常完整的。在下面的 参考资料 中，我们可以学习到更多相关知识。
虚拟化 概念很早就已出现。简单来说，虚拟化就是使用某些程序，并使其看起来类似于其他程序的过程。将这个概念应用到计算机系统中可以让不同用户看到不同的单个系统（例如，一台计算机可以同时运行 Linux 和 Microsoft® Windows®）。这通常称为全虚拟化（full virtualization）。 虚拟化也可以使用更加复杂的格式，其中单个计算机看上去具有多个架构（对于一个用户来说，它是一个标准的 x86 平台；对于另外一个用户来说，它是 IBM Power PC® 平台）。这种虚拟化形式通常被称为 硬件仿真。 最后，更加简单的一种虚拟化是操作系统虚拟化，其中一台计算机可以运行相同类型的多个操作系统。这种虚拟化可以将一个操作系统的多个服务器隔离开来（这意味着全都必须使用相同类型和版本的操作系统）。有关虚拟化方法的更多信息，请参看 参考资料。 虚拟化最常使用的两种方法是全虚拟化 和准虚拟化。使用全虚拟化，在虚拟化的操作系统和硬件之间存在一个层，用于决定访问。这个层称为系统管理程序 或虚拟机监视器（VMM）。准虚拟化与之类似，但是系统管理程序会以一种更具协作性的方式进行操作。这是因为每个客户操作系统都了解自己正在虚拟化模式中运行，因此每个系统都与系统管理程序协作，来实现底层硬件的虚拟化。 全虚拟化的例子包括商业虚拟化解决方案 VMware，以及商业 IBM zSeries® 计算机上使用的 IBM System z9 Virtual Machine（z/VM）操作系统。准虚拟化的例子有 Xen 和 User-Mode-Linux (UML)。 KVM 也被认为是一个全虚拟化解决方案，不过我们稍后再介绍这个问题。 我们首先简要介绍一下虚拟化技术及其涉及的元素。虚拟化解决方案的底部是要进行虚拟化的机器。这台机器可能直接支持虚拟化，也可能不会直接支持虚拟化；那么就需要系统管理程序 层的支持。系统管理程序，或称为 VMM，可以看作是平台硬件和操作系统的抽象化。在某些情况中，这个系统管理程序就是一个操作系统；此时，它就称为主机操作系统，如 图 1 所示。 系统管理程序之上是客户机操作系统，也称为虚拟机（VM）。这些 VM 都是一些相互隔离的操作系统，将底层硬件平台视为自己所有。但是实际上，是系统管理程序为它们制造了这种假象。 目前使用虚拟化解决方案的问题是，并非所有硬件都可以很好地支持虚拟化。较老的 x86 处理器根据执行范围对特定指令会产生不同结果。这就产生了一个问题，因为系统管理程序应该只能在一个最受保护的范围中执行。由于这个原因，诸如 VMWare 之类的虚拟化解决方案会提前扫描要执行的代码，从而将这些指令替换为一些陷阱指令（trap instruction），这样系统管理程序就可以正确地处理它们。Xen 可以支持一种协作的虚拟化方法，它不需要任何修改，因为客户机知道自己正在进行虚拟化，并已经进行了修改。KVM 会简单地忽略这个问题，如果您希望进行虚拟化，就强制必须在更新的硬件上运行。 刚开始会觉得这有些不方便，但是考虑到目前上市的较新机器都可以支持虚拟化（例如 Intel® VT 和 AMD SVM），用不了多久，这将成为标准方法而不是少数例外情况。有关可以支持虚拟化的处理器的更多信息，请参看 参考资料 和侧栏 处理器对于虚拟化的支持。 考虑到虚拟化技术的发展时间并不长，KVM 实际上还是一种相对来说比较新的技术。目前存在各具功能的开源技术，例如 Xen、Bochs、UML、Linux-VServer 和 coLinux，但是 KVM 目前正在被大量使用。另外，KVM 不再仅仅是一个全虚拟化解决方案，而将成为更大的解决方案的一部分。 KVM 所使用的方法是通过简单地加载内核模块而将 Linux 内核转换为一个系统管理程序。这个内核模块导出了一个名为 /dev/kvm 的设备，它可以启用内核的客户模式（除了传统的内核模式和用户模式）。有了 /dev/kvm 设备，VM 使自己的地址空间独立于内核或运行着的任何其他 VM 的地址空间。设备树（/dev）中的设备对于所有用户空间进程来说都是通用的。但是每个打开 /dev/kvm 的进程看到的是不同的映射（为了支持 VM 间的隔离）。 KVM 然后会简单地将 Linux 内核转换成一个系统管理程序（在安装 kvm 内核模块时）。由于标准 Linux 内核就是一个系统管理程序，因此它会从对标准内核的修改中获益良多（内存支持、调度程序等）。对这些 Linux 组件进行优化（例如 2.6 版本内核中的新 O(1) 调度程序）都可以让系统管理程序（主机操作系统）和 Linux 客户操作系统同时受益。但是 KVM 并不是第一个这样做的程序。UML 很久以前就将 Linux 内核转换成一个系统管理程序了。使用内核作为一个系统管理程序，您就可以启动其他操作系统，例如另一个 Linux 内核或 Windows 系统。 安装 KVM 之后，您可以在用户空间启动客户操作系统。每个客户操作系统都是主机操作系统（或系统管理程序）的一个单个进程。图 2 提供了一个使用 KVM 进行虚拟化的视图。底部是能够进行虚拟化的硬件平台（目前指的是 Intel VT 或 AMD-SVM 处理器）。在裸硬件上运行的是系统管理程序（带有 KVM 模块的 Linux 内核）。这个系统管理程序与可以运行其他应用程序的普通 Linux 内核类似。但是这个内核也可以支持通过 kvm 工具加载的客户操作系统。最后，客户操作系统可以支持主机操作系统所支持的相同应用程序。 记住 KVM 只是虚拟化解决方案的一部分。处理器直接提供了虚拟化支持（可以为多个操作系统虚拟化处理器）。内存可以通过 kvm 进行虚拟化（这在下一节中将会讨论）。最后，I/O 通过一个稍加修改的 QEMU 进程（执行每个客户操作系统进程的一个拷贝）进行虚拟化。 KVM 向 Linux 中引入了一种除现有的内核和用户模式之外的新进程模式。这种新模式就称为客户 模式，顾名思义，它用来执行客户操作系统代码（至少是一部分代码）。回想一下内核模式表示代码执行的特权模式，而用户模式则表示非特权模式（用于那些运行在内核之外的程序）。根据运行内容和目的，执行模式可以针对不同的目的进行定义。客户模式的存在就是为了执行客户操作系统代码，但是只针对那些非 I/O 的代码。在客户模式中有两种标准模式，因此客户操作系统在客户模式中运行可以支持标准的内核，而在用户模式下运行则支持自己的内核和用户 空间应用程序。客户操作系统的用户模式可以用来执行 I/O 操作，这是单独进行管理的。 在客户操作系统上执行 I/O 的功能是由 QEMU 提供的。QEMU 是一个平台虚拟化解决方案，允许对一个完整的 PC 环境进行虚拟化（包括磁盘、图形适配器和网络设备）。客户操作系统所生成的任何 I/O 请求都会被中途截获，并重新发送到 QEMU 进程模拟的用户模式中。 KVM 通过 /dev/kvm 设备提供了内存虚拟化。每个客户操作系统都有自己的地址空间，并且是在实例化客户操作系统时映射的。映射给客户操作系统的物理内存实际上是映射给这个进程的虚拟内存。为了支持客户物理地址到主机物理地址的转换，系统维护了一组影子页表（shadow page table）。处理器也可以通过在访问未经映射的内存位置时使用系统管理程序（主机内核）来支持内存转换进程。 新客户操作系统的实例化是由一个名为 通过一组在 /dev/kvm 设备上执行的 ioctls 可以提供控制支持。当第一次打开这个特殊文件时，就会创建一个新的 VM 对象，它与一个虚拟 CPU 关联在一起。您然后可以使用几个 ioctls 来创建一个虚拟 CPU，检查 kvm 版本，创建内存区域，然后启动一个虚拟 CPU。您可以使用 如果硬件支持的话，使用 KVM 实际上非常简单。您需要一个具有虚拟化支持的处理器。通过查看 /proc/cpuinfo 可以知道系统是否支持虚拟化。这个文件指定了是否支持 vmx（Intel）或 svm（AMD）扩展。 接下来，您需要一个启用了 KVM 支持的 Linux 内核。您可以在 Device Drivers > Virtualization 下的内核配置中完成这种配置。还必须启用处理器对环境的支持。另外，还必须具有 kvm 和 qemu 用户空间应用程序。更多信息请参见 参考资料。 有了启用了虚拟化支持的引导内核，接下来的一个步骤是为客户操作系统创建一个磁盘映像。您可以使用
在创建虚拟磁盘之后，就可以将客户操作系统加载到其上。下面的例子假设客户操作系统是在 CD-ROM 上。除了使用 CD-ROM ISO 映像来填充虚拟磁盘之外，还必须在结束时启动这个映像。
Ari Kivity 已经编写了一组测试工具来测试 KVM，而不需要全部的设备模型。下面的代码片断（来自于 kvm-12/user/main.c）从较高的层次上查看了 VM 的启动（请参见 清单 1）。控制特性是由内核中的 ioctls 提供的（具体来说，在 ./linux-2.6.20/drivers/kvm/kvm_main.c 文件中）。 对
KVM 是解决虚拟化问题的一个有趣的解决方案，但是由于它是第一个进入内核的虚拟化解决方案，很难想象它会很快用于服务器虚拟化。还有其他一些方法一直在为进入内核而竞争（例如 UML 和 Xen），但是由于 KVM 需要的修改较少，并且可以将标准内核转换成一个系统管理程序，因此它的优势不言而喻。 KVM 的另外一个优点是它是内核本身的一部分，因此可以利用内核的优化和改进。与其他独立的系统管理程序解决方案相比，这种方法是一种不会过时的技术。KVM 两个最大的缺点是需要较新的能够支持虚拟化的处理器，以及一个用户空间的 QEMU 进程来提供 I/O 虚拟化。但是不论好坏，KVM 位于内核中，这对于现有解决方案来说是一个巨大的飞跃。 学习 获得产品和技术 讨论 M. Tim Jones 是一名嵌入式软件工程师，他是 GNU/Linux Application Programming、AI Application Programming以及 BSD Sockets Programming from a Multilanguage Perspective 等书的作者。他的工程背景非常广泛，从同步宇宙飞船的内核开发到嵌入式架构设计，再到网络协议的开发。Tim 是位于科罗拉多州 Longmont 的 Emulex Corp. 的一名顾问工程师。
本文探索了一些支持实时特性的 Linux 架构，并探讨了实时架构 的含意是什么。有许多种解决方案赋予 Linux 实时能力，本文将对瘦内核（或微内核）方法、超微内核方法以及资源内核（resource-kernel）方法进行考查。最后,描述了标准 2.6 内核的实时功能，并向您示范如何启用并使用这种功能。 下列实时 的定义为探讨实时 Linux 架构提供了基础。定义由 Donal Gillies 在 Realtime Computing FAQ 中提出（参见 参考资料 的链接）。 换句话说，系统面对变化的负载（从最小到最坏的情况）时必须确定性地保证满足时间要求。注意，上述定义并未提到性能，原因是实时性与速度关系不大：它与可预见性有关。例如，使用快速的现代处理器时，Linux 可以提供 20 μ 微秒的典型中断响应，但有时候响应会变得很长。这是一个基本的问题：并不是 Linux 不够快或效率不够高，而是因为它不能提供确定性。 一些例子将演示全部这些内容的含意。图 1 显示的是中断延迟指标。当中断到达时（event），CPU 发生中断并转入中断处理。执行一些工作以确定发生了什么事件，然后执行少量工作分配必需的任务以处理此事件（上下文切换）。中断到达与分发必需任务之间的时间（假设分配的是优先级最高的任务）称为响应时间。对于实时性要求，响应时间应是确定的并应当在已知的最坏情况的时间内完成。 有关这个过程的一个例子就是目前汽车中使用的气囊。当报告车辆碰撞的传感器中断 CPU 后，操作系统应快速地分配展开气囊的任务，并且不允许其他非实时处理进行干扰。晚一秒钟展开气囊比没有气囊的情况更糟糕。 除为中断处理提供确定性外，实时处理也需要支持周期性间隔的任务调度。考虑图 2。本图演示了周期性任务调度。大量控制系统要求周期性采样与处理。某个特定任务必须按照固定的周期（p）执行，从而确保系统的稳定性。考虑一下汽车的防抱死系统（ABS）。控制系统对车辆的每个车轮的转速进行采样（每秒最多 20 次）并控制每个制动器的压力（防止它锁死）。为了保持控制系统的正常工作，传感器的采样与控制必须按照一定的周期间隔。这意味着必须抢占其他处理，以便 ABS 任务能按照期望的周期执行。 能够在指定的期限完成实时任务（即便在最坏的处理负载下也能如此）的操作系统称为硬实时 系统。但并不是任何情况下都需要硬实时支持。如果操作系统在平均情况下能支持任务的执行期限，则称它为软实时 系统。硬实时系统指超过截止期限后将造成灾难性后果（例如展开气囊过晚或制动压力产生的滑行距离过长）的系统。软实时系统超过截止期限后并不会造成系统整体失败（如丢失视频中的一帧）。 现在您已经对实时性要求有了一些深入了解，让我们查看一些实时 Linux 架构各支持哪个级别的实时性以及如何做到这一点。 瘦内核（或微内核）方法使用了第二个内核作为硬件与 Linux 内核间的抽象接口（见图 3）。非实时 Linux 内核在后台运行，作为瘦内核的一项低优先级任务托管全部非实时任务。实时任务直接在瘦内核上运行。 瘦内核主要用于（除了托管实时任务外）中断管理。瘦内核截取中断以确保非实时内核无法抢占瘦内核的运行。这允许瘦内核提供硬实时支持。 虽然瘦内核方法有自己的优势（硬实时支持与标准 Linux 内核共存），但这种方法也有缺点。实时任务和非实时任务是独立的，这造成了调试困难。而且，非实时任务并未得到 Linux 平台的完全支持（瘦内核执行称为瘦 的一个原因）。 使用这种方法的例子有 RTLinux (现在由 Wind River Systems 专有），实时应用程序接口（RTAI）和 Xenomai。 这里瘦内核方法依赖于包含任务管理的最小内核，而超微内核法对内核进行更进一步的缩减。通过这种方式，它不像是一个内核而更像是一个硬件抽象层（HAL）。超微内核为运行于更高级别的多个操作系统提供了硬件资源共享（见图 4）。因为超微内核对硬件进行了抽象，因此它可为更高级别的操作系统提供优先权，从而支持实时性。 注意，这种方法和运行多个操作系统的虚拟化方法有一些相似之处。使用这种方法的情况下，超微内核在实时和非实时内核中对硬件进行抽象。这与 hypervisor 从客户（guest）操作系统对裸机进行抽象的方式很相似。更多信息参见 参考资料 。 关于超微内核的示例是操作系统的 Adaptive Domain Environment for Operating Systems (ADEOS)。ADEOS 支持多个并发操作系统同步运行。当发生硬件事件后，ADEOS 对链中的每个操作系统进行查询以确定使用哪一个系统处理事件。 另一个实时架构是资源内核法。这种方法为内核增加一个模块，为各种资源提供预留（reservation）。这种机制保证了对时分复用（time-multiplexed）系统资源的访问（CPU、网络或磁盘带宽）。这些资源拥有多个预留参数，如循环周期、需要的处理时间（也就是完成处理所需的时间），以及截止时间。 资源内核提供了一组应用程序编程接口（API），允许任务请求这些预留资源（见图 5）。然后资源内核可以合并这些请求，使用任务定义的约束定义一个调度，从而提供确定的访问（如果无法提供确定性则返回错误）。通过调度算法，如 Earliest-Deadline-First (EDF)，内核可以处理动态的调度负载。 资源内核法实现的一个示例是 CMU 公司的 Linux/RK，它把可移植的资源内核集成到 Linux 中作为一个可加载模块。这种实现演化成商用的 TimeSys Linux/RT 产品。 目前探讨的这些方法在架构上都很有趣，但是它们都在内核的外围运行。然而，如果对标准 Linux 内核进行必要的修改使其支持实时性，结果会怎么样呢？ 今天，在 2.6 内核中，通过对内核进行简单配置使其完全可抢占（见图 6），您就可以得到软实时功能。在标准 2.6 Linux 内核中，当用户空间的进程执行内核调用时（通过系统调用），它便不能被抢占。这意味着如果低优先级进程进行了系统调用后，高优先级进程必须等到调用结束后才能访问 CPU。新的配置选项 但这种配置选项也是一种折衷。虽然此选项实现了软实时性能并且即使在负载条件下也可使操作系统顺利地运行，但这样做也付出了代价。代价就是略微减低了吞吐量以及内核性能，原因是 在 2.6 内核中另一项有用的配置选项是高精度定时器。这个新选项允许定时器以 1μs 的精度运行（如果底层硬件支持的话），并通过红黑树实现对定时器的高效管理。通过红黑树，可以使用大量的定时器而不会对定时器子系统（O(log n)）的性能造成影响。 只需要一点额外的工作，您就可以通过 PREEMPT_RT 补丁实现硬实时。PREEMPT_RT 补丁提供了多项修改，可实现硬实时支持。其中一些修改包括重新实现一些内核锁定原语，从而实现完全可抢占，实现内核互斥的优先级继承，并把中断处理程序转换为内核线程以实现线程可抢占。 Linux 不仅是一个实验和描述实时算法的理想平台，目前在标准的 2.6 内核中也实现了实时功能。从标准内核中您可以实现软实时功能，再执行一些额外的工作（内核补丁）您就可以构建硬实时应用程序。 本文简要介绍了一些为 Linux 内核提供实时计算的技术。很多早期的尝试使用瘦内核方法把实时任务与标准内核分离。后来，出现了超微内核法，它与如今的虚拟化解决方案中使用的 hypervisor 非常相似。最后，Linux 内核提供了自己的实时方法，包括软实时和硬实时。 虽然本文只是对 Linux 的实时方法进行了简单介绍，但 参考资料 一节中提供了更多的信息，可以从中获得额外的信息和其他有用的实时技术。 学习 获得产品和技术 讨论
虽然对于网络的正式介绍一般都参考了 OSI（Open Systems Interconnection）模型，但是本文对 Linux 中基本网络栈的介绍分为四层的 Internet 模型（如图 1 所示）。 这个栈的最底部是链路层。链路层是指提供对物理层访问的设备驱动程序，这可以是各种介质，例如串口链路或以太网设备。链路层上面是网络层，它负责将报文定向到目标位置。再上一层称为传输层，负责端到端的通信（例如，在一台主机内部）。尽管网络层负责管理主机之间的通信，但是传输层需要负责管理主机内部各端之间的通信。最后一层是应用层，它通常是一个语义层，能够理解要传输的数据。例如，超文本传输协议（HTTP）就负责传输服务器和客户机之间对 Web 内容的请求与响应。 实际来说，网络栈的各个层次有一些更为人所熟知的名字。在链路层上，可以找到以太网，这是最常用的一种高速介质。更早的链路层协议包括一些串口协议，例如 SLIP（Serial Line Internet Protocol）、CSLIP（Compressed SLIP）和PPP（Point-to-Point Protocol）。最常见的网络层协议是 IP（Internet Protocol），但是网络层中还存在一些满足其他需求的协议，例如 ICMP（Internet Control Message Protocol）和ARP（ Address Resolution Protocol）。在传输层上是 TCP（Transmission Control Protocol）和 UDP（User Datagram Protocol）。最后，应用层中包含很多大家都非常熟悉的协议，包括标准的 Web 协议 HTTP 和电子邮件协议 SMTP（Simple Mail Transfer Protocol）。 现在继续了解 Linux 网络栈的架构以及如何实现这种 Internet 模型。图 2 提供了 Linux 网络栈的高级视图。最上面是用户空间层，或称为应用层，其中定义了网络栈的用户。底部是物理设备，提供了对网络的连接能力（串口或诸如以太网之类的高速网络）。中间是内核空间，即网络子系统，也是本文介绍的重点。流经网络栈内部的是 socket 缓冲区（ 首先，让我们来快速浏览一下 Linux 网络子系统的核心元素，后续章节中会更详细进行介绍。顶部（请参阅图 2）是系统调用接口。它简单地为用户空间的应用程序提供了一种访问内核网络子系统的方法。位于其下面的是一个协议无关层，它提供了一种通用方法来使用底层传输层协议。然后是实际协议，在 Linux 中包括内嵌的协议 TCP、UDP，当然还有 IP。然后是另外一个协议无关层，提供了与各个设备驱动程序通信的通用接口，最下面是设备驱动程序本身。 系统调用接口可以从两个角度进行描述。用户发起网络调用时，通过系统调用接口进入内核的过程应该是多路的。最后调用 ./net/socket.c 中的 socket 层是一个协议无关接口，它提供了一组通用函数来支持各种不同协议。socket 层不但可以支持典型的 TCP 和 UDP 协议，而且还可以支持 IP、裸以太网和其他传输协议，例如 SCTP（Stream Control Transmission Protocol）。 通过网络栈进行的通信都需要对 socket 进行操作。Linux 中的 socket 结构是 网络子系统可以通过一个定义了自己功能的特殊结构来了解可用协议。每个协议都维护了一个名为 网络协议这一节对一些可用的特定网络协议作出了定义（例如 TCP、UDP 等）。它们都是在 linux/net/ipv4/af_inet.c 文件中一个名为 通过 linux/net/ipv4/ 目录中 udp.c 和 raw.c 文件中的 注意在 图 3 中， socket 中的数据移动是使用一个所谓的 socket 缓冲区（ 如图所示，多个 针对给定的 socket，Socket 缓冲区可以链接在一起，这样可以包含众多信息，包括到协议头的链接、时间戳（报文是何时发送或接收的），以及与这个报文相关的设备。 协议层下面是另外一个无关接口层，它将协议与具有很多各种不同功能的硬件设备连接在一起。这一层提供了一组通用函数供底层网络设备驱动程序使用，让它们可以对高层协议栈进行操作。 首先，设备驱动程序可能会通过调用 要从协议层向设备中发送 报文的接收通常是使用 最近，内核中引入了一种新的应用程序编程接口（NAPI），该接口允许驱动程序与设备无关层（ 网络栈底部是负责管理物理网络设备的设备驱动程序。例如，包串口使用的 SLIP 驱动程序以及以太网设备使用的以太网驱动程序都是这一层的设备。 在进行初始化时，设备驱动程序会分配一个 设备驱动程序在 Linux 源代码是学习有关大多数设备类型的设备驱动程序设计最佳方法，包括网络设备驱动程序。在这里可以找到的是各种设计的变化以及对可用内核 API 的使用，但是所学到的每一点都会非常有用，都可以作为新设备驱动程序的起点。除非您需要一种新协议，否则网络栈中的其余代码都是通用的，都会非常有用。即使现在，TCP（用于流协议）或 UDP（用于基于消息的协议）的实现都可以作为开始新开发有用模块使用。 学习 获得产品和技术 讨论
公共网络（比如 Internet）充满着危险。只要将电脑连接到 Internet（即使只连接很短的时间），您就会感受到这一点。攻击者可以利用不安全性来获得对一个系统的访问，获得对信息的未授权访问，或者对一台计算机进行改造，以利用它发送垃圾邮件或攻击其他高端系统（使用 SYN 泛洪攻击，一种分布式拒绝服务攻击）。 分布式拒绝服务攻击（DDoS）通过 Internet 上的多个系统来实现（所以也称为僵尸电脑），这些系统消耗目标系统上的资源，（利用 TCP 的三向握手）使其不能被合法的用户访问。一种带有 cookie 的四向握手协议（Stream Control Transmission Protocol [SCTP]）可以防御这种攻击，更多信息请参见 参考资料 一节。 GNU/Linux 非常安全，但它也非常动态：所做的更改会为操作系统带来新的漏洞，这些漏洞可能被攻击者利用，尽管人们都非常关心阻止未授权访问，但是发生入侵后会发生什么呢？ 本文将探究 SELinux 背后的思想及其基本架构。关于 SELinux 的完整描述涉及一整本书的内容（参见 参考资料 一节），所以本文只关注其基本原理，使您了解 SELinux 的重要性及其实现过程。 大多数操作系统使用访问控制来判断一个实体（用户或程序）是否能够访问给定资源。基于 UNIX® 的系统使用一种自主访问控制（discretionary access control，DAC）的形式。此方法通常根据对象所属的分组来限制对对象的访问。例如，GNU/Linux 中的文件有一个所有者、一个分组和一个权限集。权限定义谁可以访问给定文件、谁可以读取它、谁可以向其写入，以及谁可以执行它。这些权限被划分到三个用户集中，分别表示用户（文件所有者）、分组（一个用户组的所有成员）和其他（既不是文件所有者，又不是该分组的成员的所有用户）。 很多这样的访问控制都会带来一个问题，因为所利用的程序能够继承用户的访问控制。这样，该程序就可以在用户的访问层进行操作。与通过这种方式定义约束相比，使用最小特权原则 更安全：程序只能执行完成任务所需的操作。例如，如果一个程序用于响应 socket 请求，但不需要访问文件系统，那么该程序应该能够监听给定的 socket，但是不能访问文件系统。通过这种方式，如果该程序被攻击者利用，其访问权限显然是最小的。这种控制类型称为强制访问控制（MAC）。 另一种控制访问的方法是基于角色的访问控制（RBAC）。在 RBAC 中，权限是根据安全系统所授予的角色来提供的。角色的概念与传统的分组概念不同，因为一个分组代表一个或多个用户。一个角色可以代表多个用户，但它也代表一个用户集可以执行的权限。 SELinux 将 MAC 和 RBAC 都添加到了 GNU/Linux 操作系统中。下一节将探讨 SELinux 实现，以及如何将安全增强透明地添加到 Linux 内核中。 在早期的 SELinux 中，它还是一个补丁集，它提供了自己的安全性框架。这存在着一些问题，因为它将 GNU/Linux 限制到一个单独的访问控制架构。Linux 内核继承了一种通用框架，将策略从实现中分离了出来，而不是采用单一的方法。该解决方案就是 Linux 安全模块（Linux Security Module，LSM）框架。LSM 提供了一种通用的安全框架，允许将安全模型实现为可载入内核模块（参见图 1）。 在访问内部对象之前对内核代码进行修改，以调用一个代表实施函数的钩子，该实施函数实现安全策略。该函数根据预定义的策略验证操作能否继续进行。安全函数存储在一个安全操作结构中，该结构包含必须受到保护的基本操作。例如，
清单 3 的核心部分是一个调用，用于验证当前操作是否是当前任务（通过 初始化到 security_ops 中的回调钩子被动态定义为一个可载入内核模块（通过 本文不打算讨论 SELinux 策略的管理，但您可以在 参考资料 小节找到关于 SELinux 配置的更多信息。 SELinux 是目前最全面的安全框架之一，但它不是惟一的。本节回顾其他一些可用的方法。 AppArmor 最初由 Immunix 开发，随后由 Novell 维护，它是 SELinux 的替代方法，也使用了 Linux 安全模块（LSM）框架。由于 SELinux 和 AppArmor 使用了同样的框架，所以它们可以互换。AppArmor 的开发初衷是因为人们认为 SELinux 太过复杂，不适合普通用户管理。AppArmor 包含一个完全可配置的 MAC 模型和一个学习模式，在学习模式中，程序的典型行为可以转换为一个配置文件。 SELinux 的一个问题在于，它需要一个支持扩展属性的文件系统；而 AppArmor 对文件系统没有任何要求。您可以在 SUSE、OpenSUSE，以及 Ubuntu 的 Gutsy Gibbon 中找到 AppArmor。 Solaris 10 操作系统通过其增强了安全性的 Trusted Extensions 组件提供了强制访问控制。该功能适用于 MAC 和 RBAC。Solaris 通过向所有对象添加敏感性标签实现了这一点，使您能够控制设备、文件、连网访问，甚至窗口管理服务。Solaris 10 中的 RBAC 的优点在于，它通过提供对管理任务（可在以后进行分配）的细粒度控制最小化了对根访问的需求。 TrustedBSD 是一个正在进行中的项目，主要开发可靠的操作系统扩展，这些扩展最终会加入 FreeBSD 操作系统。它包括构建在 Flux Advanced Security Kernel (Flask) 安全架构之上的强制访问控制，后者包括以插件模块形式提供的类型强制和多级安全（MLS）。TrustedBSD 还合并了来自 Apple Darwin 操作系统的开源 Basic Security Module (BSM) 审计实现（BSM 最初由 Sun 引入）。BSM 是一个审计 API 和文件格式，它支持普通的审计跟踪处理。TrustedBSD 还构成了供 Security Enhanced Darwin (SEDarwin) 使用的框架。 增强操作系统内部安全性的最后一个选择是操作系统虚拟化（也称为虚拟专用服务器（virtual private servers））。一个操作系统拥有多个独立的用户空间实例，可以实现功能分离。操作系统虚拟化对在独立用户空间内部运行的应用程序功能进行了限制。例如，一个用户空间实例也许不能修改内核（载入或移除内核模块），也不能挂载或卸载文件系统。并且不允许修改内核参数（例如，通过 proc 文件系统）。任何修改其他用户实例环境的操作都是不允许的。 许多操作系统都能实现操作系统虚拟化。GNU/Linux 支持 VServer、Parallels Viruozzo Container 和 OpenVZ。在其他操作系统中，您可以找到容器（Solaris）和 jail（BSD）。在 Linux-VServer 中，每个单独的用户空间实例称为一个安全上下文。在每个安全上下文中，会为专用服务器实例启动一个新的 init。关于操作系统虚拟化和其他虚拟化方法的更多信息，请参见 参考资料 一节。 对于 Linux 内核来说，强制访问控制和基于角色的访问控制都是相对较新的功能。随着 LSM 框架的引入，新的安全模块将会出现。除了对框架的增强，还可以堆叠安全模块，从而允许多个安全模块共存，而且最大限度地覆盖了 Linux 的安全需求。随着对操作系统安全性的深入研究，将会引入新的访问控制方法。关于 LSM 和 SELinux 中的功能的详细介绍，请查阅 参考资料 一节中的文章和论文。 学习 获得产品和技术 讨论 M. Tim Jones 是一名嵌入式软件工程师，他是 GNU/Linux Application Programming、AI Application Programming以及 BSD Sockets Programming from a Multilanguage Perspective 等书的作者。他的工程背景非常广泛，从同步宇宙飞船的内核开发到嵌入式架构设计，再到网络协议的开发。Tim 是位于科罗拉多州 Longmont 的 Emulex Corp. 的一名顾问工程师。
固态驱动器当前非常流行，但是嵌入式系统很久以前就开始使用固态驱动器进行存储。您可以看到 flash 系统被用于个人数字助理（PDA）、手机、MP3 播放器、数码相机、USB flash 驱动（UFD），甚至笔记本电脑。 很多情况下，商业设备的文件系统可以进行定制并且是专有的，但是它们会遇到以下挑战。 基于 Flash 的文件系统形式多种多样。本文将探讨几种只读文件系统，并回顾目前可用的各种读/写文件系统及其工作原理。但是，让我们先看看 flash 设备及其所面对的挑战。 Flash 内存（可以通过几种不同的技术实现）是一种非挥发性内存，这意味着断开电源之后其内容仍然保持下来。要了解 flash 内存的辉煌历史，请参阅 参考资料。 两种最常见的 flash 设备类型为：NOR 和 NAND。基于 NOR 的 flash 技术比较早，它支持较高的读性能，但以降低容量为代价。NAND flash 提供更大容量的同时实现快速的写擦性能。NAND 还需要更复杂的输入/输出（I/O）接口。 Flash 部件通常分为多个分区，允许同时进行多个操作（擦除某个分区的同时读取另一个分区）。分区再划分为块（通常大小为 64KB 或 128KB）。使用分区的固件可以进一步对块进行独特的分段 — 例如，一个块中有 512 字节的分段，但不包括元数据。 Flash 设备有一个常见的限制，即与其他存储设备（如 RAM 磁盘）相比，它需要进行设备管理。flash 内存设备中惟一允许的 Write 操作是将 1 修改为 0。如果需要撤销操作，那么必须擦除整个块（将所有数据重置回状态 1）。这意味着必须删除该块中的其他有效数据来实现持久化。NOR flash 内存通常一次可以编写一个字节，而 NAND flash 内存必须编写多个字节（通常为 512 字节）。 这两种内存类型在擦除块方面有所不同。每种类型都需要一个特殊的 Erase 操作，该操作可以涵盖 flash 内存中的一个整块。NOR 技术需要通过一个准备步骤将所有值清零，然后再开始 Erase 操作。Erase 是针对 flash 设备的特殊操作，非常耗费时间。擦除操作与电有关，它将整个块的所有单元中的电子放掉。 NOR flash 设备通常需要花费几秒时间来执行 Erase 操作，而 NAND 设备只需要几毫秒。flash 设备的一个关键特性是可执行的 Erase 操作的数量。在 NOR 设备中，flash 内存中的每个块可被擦除 100,000 次，而在 NAND flash 内存中可达到一百万次。 除了前面提到的一些限制以外，管理 flash 设备还面临很多挑战。三个最重大的挑战分别是垃圾收集、管理坏块和平均读写。 垃圾收集 是一个回收无效块的过程（无效块中包含了一些无效数据）。回收过程包括将有效数据移动到新块，然后擦除无效块从而使它变为可用。如果文件系统的可用空间较少，那么通常将在后台执行这一过程（或者根据需要执行）。 用的时间长了，flash 设备就会出现坏块，甚至在出厂时就会因出现坏块而不能使用。如果 flash 操作（例如 Erase）失败，或者 Write 操作无效（通过无效的错误校正代码发现，Error Correction Code，ECC），那么说明出现了坏块。 识别出坏块后，将在 flash 内部将这些坏块标记到一个坏块表中。具体操作取决于设备，但是可以通过一组独立的预留块来（不同于普通数据块管理）实现。对坏块进行处理的过程 — 不管是出厂时就有还是在使用过程中出现 — 称为坏块管理。在某些情况下，可以通过一个内部微控制器在硬件中实现，因此对于上层文件系统是透明的。 前面提到 flash 设备属于耗损品：在变成坏块以前，可以执行有限次数的反复的 Erase 操作（因此必须由坏块管理进行标记）。平均读写算法能够最大化 flash 的寿命。平均读写有两种形式：动态平均读写 和静态平均读写 。 动态平均读写解决了块的 Erase 周期的次数限制。动态平均读写算法并不是随机使用可用的块，而是平均使用块，因此，每个块都获得了相同的使用机会。静态平均读写算法解决了一个更有趣的问题。除了最大化 Erase 周期的次数外，某些 flash 设备在两个 Erase 周期之间还受到最大化 Read 周期的影响。这意味着如果数据在块中存储的时间太长并且被读了很多次，数据会逐渐消耗直至丢失。静态平均读写算法解决了这一问题，因为它可以定期将数据移动到新块。 到目前为止，我已经讨论了 flash 设备及其面临的基本挑战。现在，让我们看看这些设备如何组合成为一个分层架构的一部分（参加图 1）。架构的顶层是虚拟文件系统（VFS），它为高级应用程序提供通用接口。VFS 下面是 flash 文件系统（将在下节介绍）。接下来是 Flash 转换层（Flash Translation Layer，FTL），它整体管理 flash 设备，包括从底层 flash 设备分配块、地址转换、动态平均读写和垃圾收集。在某些 flash 设备中，可以在硬件中实现一部分 FTL 。 Linux 内核使用内存技术设备（Memory Technology Device，MTD）接口，这是针对 flash 系统的通用接口。MTD 可以自动检测 flash 设备总线的宽度以及实现总线宽度所需设备的数量。 Linux 可以使用多种 flash 文件系统。下一小节将解释每种文件系统的设计和优点。 Journaling Flash File System 是针对 Linux 的最早 flash 文件系统之一。 JFFS 是一种专门为 NOR flash 设备设计的日志结构文件系统。它非常独特，能够解决许多 flash 设备问题，但同时也导致一些新问题。 JFFS 将 flash 设备视为一种循环的块日志。写入 flash 的数据被写到了空间的末尾，开始部分的块则被收回，而两者之间的空间是空闲的；当空间变少时，将执行垃圾收集。垃圾收集器将有效块移动到日志的尾部，跳过无效或废弃块，并擦除它们（参见图 2）。因此这种文件系统可以自动实现静态和动态平均读写。这种架构的主要缺点是过于频繁地执行擦除操作（而没有使用最佳擦除策略），从而使设备迅速磨损。 挂载 JFFS 时结构细节将读取到内存中，这将延缓挂载时间并消耗更多的内存。 Journaling Flash File System 2 尽管 JFFS 在早期非常有用，但是它的平均读写算法容易缩短 NOR flash 设备的寿命。因此重新设计了底层算法，去掉了循环日志。JFFS2 算法专门为 NAND flash 设备设计，并且改善压缩性能。 在 JFFS2 中，flash 中的每个块都是单独处理的。JFFS2 通过维护块列表来充分地对设备执行平均读写。clean 列表表示设备中的块全部为有效节点。dirty 列表中的块至少包含有一个废弃节点。最后，free 列表包含曾经执行过擦除操作并且可以使用的块。 垃圾收集算法通过合理的方法智能地判断应该回收的块。目前，这个算法根据概率从 clean 或 dirty 列表中选择。dirty 列表的选择概率为 99%（将有效内容移到另一个块），而 clean 列表的选择概率为 1%（将内容移到新的块）。在这两种情况中，对选择的块执行擦除操作，然后将其置于 free 列表（参见图 3）。这允许垃圾收集器重用废弃的块，但是仍然围绕 flash 移动数据，以支持静态平均读写。 YAFFS 是针对 NAND flash 开发的另一种 flash 文件系统。最早的版本（YAFFS）支持 512 字节页面的 flash 设备，但是较新的版本（YAFFS2）支持页面更大的新设备以及更大的 Write 限制。 大多数 flash 文件系统会对废弃块进行标记，但是 YAFFS2 使用单调递增数字序列号额外地标记块。在挂载期间扫描文件系统时，可以快速标识有效的 inode。YAFFS 保留在 RAM 中的树以表示 flash 设备的块结构，包括通过检查点（checkpointing）实现快速挂载 — 这个过程将在正常卸载时将 RAM 树结构保存到 flash 设备，以在挂载时快速读取和恢复到 RAM（参见图 4）。与其他 flash 文件系统相比，YAFFS2 的挂载时性能是它的最大优势。 在某些嵌入式系统中，没有必要提供可更改的文件系统：一个不可更改（immutable）的文件系统已经足够。Linux 支持多种只读文件系统，最有用的两种是 cramfs 和 SquashFS。 cramfs 文件系统是一种可用于 flash 设备的压缩式 Linux 只读文件系统。cramfs 的主要特点是简单和较高的空间利用率。这种文件系统用于内存占用较小的嵌入式设计。 虽然 cramfs 元数据没有经过压缩，但是 cramfs 针对每个页面使用 zlib 压缩，从而允许随机的页面访问（访问时对页面进行解压缩）。 您可以通过 SquashFS 是另一种可用于 flash 设备的压缩式 Linux 只读文件系统。您可以在很多 Live CD Linux 发行版中找到 SquashFS。除了支持 zlib 压缩外，SquashFS 还使用 Lembel-Ziv-Markov chain Algorithm (LZMA) 改善压缩并提高速度。 和 cramfs 一样，您可以通过 和大多数开放源码一样，软件在不断演变，并且新的 flash 文件系统正在开发之中。一种还处于开发阶段的有趣的备选文件系统是 LogFS，它包含了一些非常新颖的想法。例如，LogFS 在 flash 设备中保持了一个树结构，因此挂载时间和传统的文件系统差不多（比如 ext2）。它还使用一种复杂的树实现垃圾收集（一种 B+树形式）。然而，LogFS 最有趣的地方是它具有出色的可伸缩性并且支持大型 flash 部件。 随着 flash 文件系统的日益流行，您将看到针对它们的大量研究。LogFS 就是一个例子，但是其他类似于 UbiFS 的文件系统也在不断发展。Flash 文件系统的架构非常有趣，并在还将是未来技术创新的源泉。 学习 获得产品和技术 讨论
Linux 文件系统体系结构是一个对复杂系统进行抽象化的有趣例子。通过使用一组通用的 API 函数，Linux 可以在许多种存储设备上支持许多种文件系统。例如， 首先回答最常见的问题，“什么是文件系统”。文件系统是对一个存储设备上的数据和元数据进行组织的机制。由于定义如此宽泛，支持它的代码会很有意思。正如前面提到的，有许多种文件系统和媒体。由于存在这么多类型，可以预料到 Linux 文件系统接口实现为分层的体系结构，从而将用户接口层、文件系统实现和操作存储设备的驱动程序分隔开。 在 Linux 中将一个文件系统与一个存储设备关联起来的过程称为挂装（mount）。使用 为了说明 Linux 文件系统层的功能（以及挂装的方法），我们在当前文件系统的一个文件中创建一个文件系统。实现的方法是，首先用
现在有了一个 10MB 的 file.img 文件。使用
这个文件现在作为一个块设备出现（由 /dev/loop0 表示）。然后用
使用
如清单 4 所示，还可以继续这个过程：在刚才挂装的文件系统中创建一个新文件，将它与一个循环设备关联起来，再在上面创建另一个文件系统。
通过这个简单的演示很容易体会到 Linux 文件系统（和循环设备）是多么强大。可以按照相同的方法在文件上用循环设备创建加密的文件系统。可以在需要时使用循环设备临时挂装文件，这有助于保护数据。 既然已经看到了文件系统的构造方法，现在就看看 Linux 文件系统层的体系结构。本文从两个角度考察 Linux 文件系统。首先采用高层体系结构的角度。然后进行深层次讨论，介绍实现文件系统层的主要结构。 尽管大多数文件系统代码在内核中（后面讨论的用户空间文件系统除外），但是图 1 所示的体系结构显示了用户空间和内核中与文件系统相关的主要组件之间的关系。 用户空间包含一些应用程序（例如，文件系统的使用者）和 GNU C 库（glibc），它们为文件系统调用（打开、读取、写和关闭）提供用户接口。系统调用接口的作用就像是交换器，它将系统调用从用户空间发送到内核空间中的适当端点。 VFS 是底层文件系统的主要接口。这个组件导出一组接口，然后将它们抽象到各个文件系统，各个文件系统的行为可能差异很大。有两个针对文件系统对象的缓存（inode 和 dentry）。它们缓存最近使用过的文件系统对象。 每个文件系统实现（比如 ext2、JFS 等等）导出一组通用接口，供 VFS 使用。缓冲区缓存会缓存文件系统和相关块设备之间的请求。例如，对底层设备驱动程序的读写请求会通过缓冲区缓存来传递。这就允许在其中缓存请求，减少访问物理设备的次数，加快访问速度。以最近使用（LRU）列表的形式管理缓冲区缓存。注意，可以使用 这就是 VFS 和文件系统组件的高层情况。现在，讨论实现这个子系统的主要结构。 Linux 以一组通用对象的角度看待所有文件系统。这些对象是超级块（superblock）、inode、dentry 和文件。超级块在每个文件系统的根上，超级块描述和维护文件系统的状态。文件系统中管理的每个对象（文件或目录）在 Linux 中表示为一个 inode。inode 包含管理文件系统中的对象所需的所有元数据（包括可以在对象上执行的操作）。另一组结构称为 dentry，它们用来实现名称和 inode 之间的映射，有一个目录缓存用来保存最近使用的 dentry。dentry 还维护目录和文件之间的关系，从而支持在文件系统中移动。最后，VFS 文件表示一个打开的文件（保存打开的文件的状态，比如写偏移量等等）。 VFS 作为文件系统接口的根层。VFS 记录当前支持的文件系统以及当前挂装的文件系统。 可以使用一组注册函数在 Linux 中动态地添加或删除文件系统。内核保存当前支持的文件系统的列表，可以通过 /proc 文件系统在用户空间中查看这个列表。这个虚拟文件还显示当前与这些文件系统相关联的设备。在 Linux 中添加新文件系统的方法是调用 在注册新的文件系统时，会把这个文件系统和它的相关信息添加到 file_systems 列表中（见图 2 和 linux/include/linux/mount.h）。这个列表定义可以支持的文件系统。在命令行上输入 VFS 中维护的另一个结构是挂装的文件系统（见图 3）。这个结构提供当前挂装的文件系统（见 linux/include/linux/fs.h）。它链接下面讨论的超级块结构。 超级块结构表示一个文件系统。它包含管理文件系统所需的信息，包括文件系统名称（比如 ext2）、文件系统的大小和状态、块设备的引用和元数据信息（比如空闲列表等等）。超级块通常存储在存储媒体上，但是如果超级块不存在，也可以实时创建它。可以在 ./linux/include/linux/fs.h 中找到超级块结构（见图 4）。 超级块中的一个重要元素是超级块操作的定义。这个结构定义一组用来管理这个文件系统中的 inode 的函数。例如，可以用 inode 表示文件系统中的一个对象，它具有惟一标识符。各个文件系统提供将文件名映射为惟一 inode 标识符和 inode 引用的方法。图 5 显示 inode 结构的一部分以及两个相关结构。请特别注意 inode 和目录缓存分别保存最近使用的 inode 和 dentry。注意，对于 inode 缓存中的每个 inode，在目录缓存中都有一个对应的 dentry。可以在 ./linux/include/linux/fs.h 中找到 除了各个文件系统实现（可以在 ./linux/fs 中找到）之外，文件系统层的底部是缓冲区缓存。这个组件跟踪来自文件系统实现和物理设备（通过设备驱动程序）的读写请求。为了提高效率，Linux 对请求进行缓存，避免将所有请求发送到物理设备。缓存中缓存最近使用的缓冲区（页面），这些缓冲区可以快速提供给各个文件系统。 本文没有讨论 Linux 中可用的具体文件系统，但是值得在这里稍微提一下。Linux 支持许多种文件系统，包括 MINIX、MS-DOS 和 ext2 等老式文件系统。Linux 还支持 ext3、JFS 和 ReiserFS 等新的日志型文件系统。另外，Linux 支持加密文件系统（比如 CFS）和虚拟文件系统（比如 /proc）。 最后一种值得注意的文件系统是 Filesystem in Userspace（FUSE）。这种文件系统可以将文件系统请求通过 VFS 发送回用户空间。所以，如果您有兴趣创建自己的文件系统，那么通过使用 FUSE 进行开发是一种不错的方法。
|
