| 模块子系统 - 设备驱动程序
在 Linux 2.6的开发历程中，模块子系统是另一有重大改进的部分。许多代码被重写，以提高稳定性，并使系统更加透明。除了这些明显的表层的变化之外，还有更多背后的内核如何看待以及使用模块的改变。 首先，Linux 2.6中内核驱动程序最显而易见的（虽然并没有太大作用）的变化是文件扩展名改变了。".ko"（kernel object，内核目标文件）取代了".o"（这是一目标文件的常见扩展名，通常在程序编译期间，链接生成可执行应用程序之前创建）。与其说这使得模块并 不是真正的中间文件这一点更为清楚，还不如说这仅仅是一个装饰性（cosmetic）的改动。 完完全全实质性的改进在于消除存在于很多内核版本中的竞态的多方面工作。问题的关键在于，如果卸载发生在模块检查并确认没有其它的设备正在使 用它之后，使用一个正在被卸载的模块来启动设备是有可能的。新的内核模块代码应使得这一条件更难被触发。更进一步，现在简单地完全禁止模块卸载也是有可能 的。 更加透明是新的模块子系统另一特性。在此之前，几乎所有的 Linux版本中，模块是足够智能的，它们可以通过扫描总线寻找它识别（recognized）的设备ID号，检测到它所能够支持的设备（比如PCI， ISA PnP以及PC卡）。Linux 2.6标准化了这种支持，使之对内核来说外部化，外部程序以及模块加载器判断一个特定的模块可以支持哪些设备将更为容易。这将允许各种硬件管理程序（比如 Redhat的kudzu）对硬件作出智能化的判断，即使他们本身对自己所处理的硬件设备并不熟悉。如果你的知识超越了当前版本的驱动程序，你可以（通过 新的 sys文件系统中的一个接口）强制一个驱动程序工作于某一特定的设备，即使驱动程序并不知道自己可以支持该设备。 其他改进 除了上述的许多改变之外，还有很多其他可以提升系统性能的普遍性的改变。这其中包括更多的去除了"Big kernel Lock"（早期Linux用于支持SMP系统时所采用的非细粒度锁），以及针对文件系统预读、回写和小文件操作的优化等。 Linux 2.6还解决了一个更为深刻的稳定性问题：内核将不会分配多于系统中RAM（加swap）数量的内存。此前，Linux在一些即使系统内存耗尽的情况下， 仍然允许malloc操作分配内存成功。过量分配（overcommitment）逻辑得到修改，使得这种情况现在不再可能出现。（当然，如果你耗尽了系 统的RAM，即使没有超越最大可用数量--你需要担心更更严重的问题。） Linux总是一个开放标准的支持者。内核内部的大改变之一就是Linux的线程框架被重写，以使NPTL（Native POSIX Thread Library）可以运行于其上。对于运行负荷繁重的线程应用的Pentium Pro以及更先进的处理器而言，这是一个主要的性能提升；它也是企业级应用中的很多高端系统一直以来所期待的。（实际上，RedHat已经将它向后移植到 了Linux 2.4，从RedHat 9.0中开始包含）线程框架的改变包含LInux线程空间中的许多新的概念，包括线程组、线程各自的本地存储区、POSIX风格信号以及其他改变。主要的 缺点之一是依赖于老式的Linux-isms而没有遵循POSIX标准的应用程序（比如Sun Java）将不能运行在支持新式线程的系统之上。鉴于使用新的线程模型利远大于弊，很明显，新的内核发布不久，最为重要的那些应用都将会支持这个改变。 最后，2.6可以支持编译时关闭内核对存储交换（swap）的支持，尽管对于绝大多数Linux之上的应用而言，没有直接的益处。这使得Linux可以在相对小的内存足迹（footprint）内运行，对于不大可能使用交换设备的嵌入式系统可能也是有益的。 |
