要点：Linux 2.4 - 第二部分
偶尔，会发生一些惊天动地、令人惊叹的事情，从而改变世界。Linux 2.4 仍然不是其中之一。Linus 的快速发布计划实际上并没有快速产生新的内核，至少没有达到许多开发者（包括我自己）预期的速度。本文是“要点”（2000 年 1 月）的附录，也是“Linux 2.4 焦点：ISA 即插即用”（2000 年 2 月）的后续。要更全面地了解 Linux 2.4，请参阅 “Linux 2.4 记分卡” 和 “Linux 2.4 的奇妙世界”，可在 Linux Today 上找到 (www.linuxtoday.com)。
Linux 2.2 在其 “预发布” 阶段只用了一个多月，2.0 也是如此。虽然 2.4 内核正处于最后的开发周期，但这个预发布系列已经延长了几个月，而且仍然难以预测官方发布需要多长时间。2.2 内核有一些 “brown bag” 问题，我相信 Linus 不会想重蹈覆辙。根据最近的 2.4 错误列表，当前预发布版本中有 12 个非常重要的错误需要修复，26 个不太重要的错误，还有几个更小的次要错误，以及许多需要合并和验证的东西以及其他类似的事情。这个列表每天都在缩小，但仍然是一个很大的列表。
Alan Cox 最近在 “ac” 系列内核上的工作有助于稳定代码，但仍有许多项目留在 “必须修复” 列表中。我预计 2.4 将在几个月内发布。然而，实际的发布日期将完全取决于 Linus。
现在，不分先后顺序，介绍更多 Linux 2.4 的新功能。
几乎每个 UNIX 变体都通过一个通用模型访问块设备和字符设备：/dev 目录中的特殊设备文件。不幸的是，不同的 UNIX 变体以截然不同的方式命名这些设备。例如，BSD 变体将硬盘称为 /dev/wd* 而不是 /dev/hd*。（字符 “wd” 代表 Western Digital，IDE 硬盘的制造商。）与 Linux 不同，一些 UNIX 变体也使用 /dev 目录来表示网络设备（例如，eth0）。
虽然设备命名在 UNIX 变体中有所不同，但这些设备与内核通信的方法通常是相同的。在 Linux 2.2 下，每个可访问设备的特殊文件（设备节点）都放置在 /dev 目录中。设备节点只是两个值，一个主设备号和一个次设备号。主设备号通常对应于 Linux 内核中的驱动程序或子系统。次设备号通常对应于子功能或子设备（例如，硬盘上的特定分区）。通信实际上是通过这些数字完成的。设备节点的名称是标准化的，但管理员可以随意命名。（如今，所有 Linux 发行版都使用与内核一起提供的文档中相同的标准命名方案。）
2.2 /dev 模型有几个缺点。首先，它使用有限的数字命名空间。不可避免地，我们在标准中命名新设备时会用完数字。其次，现代设备（如 USB）与主/次设备号的安排不太协调。即使是复杂的分区方案也揭示了当前基础架构的局限性。由于不可能预先知道用户将在其系统上安装哪些设备，因此发行版会在 /dev 目录中创建数百个（有时超过一千个）设备节点。在给定的机器上只使用了少数几个；其余的仍然是为了满足所有兼容硬件设备的所有可能配置。仔细想想，这有点疯狂。为了更好地满足更即插即用世界的需求，Linux 2.4 引入了设备文件系统 (DevFS)：在对 /dev 的优雅改造中，仅列出配置的设备。
DevFS 是一个基于内核的文件系统。与 /proc 类似，DevFS 在文件系统树中可见（作为 /dev），但永远不会 “同步” 到物理设备；/dev 保留在 RAM 中。每当驱动程序加载到内核并且检测到设备时，都会将相应的条目添加到 /dev 树中。
除了清理文件系统树之外，DevFS 也会更快。这是它的工作原理。通信是直接的；当您 open() 一个文件时，您直接与驱动程序通信。在 2.2 下，当 open() 一个普通设备节点时，内核会在表中查找主设备号并调用一个函数。然后，实际的驱动程序使用次设备号计算出特定的设备。DevFS 移除了一层间接层。现在程序与驱动程序对话，而不是节点。
随着 DevFS 的引入和设备节点的弃用，Linus 认为 2.2 设备节点过于局限，即将被淘汰。几乎所有 DevFS 节点名称都与它们的主/次设备号对应项不同，通常非常不同。设备类现在在子目录中分类（结构上类似于 /proc/scsi/*）。为了与 2.2 系统兼容，管理员仍然可以使用旧式节点（使用 devfsd d<#230>mon），但它们已被弃用。
不幸的是，DevFS 也存在一些问题。在新系统中，权限更难管理。设备权限由驱动程序分配，而不是由文件系统中的节点分配。可以更改权限，但每次加载模块（或重新启动时）都会忘记这些权限。驱动程序（内核的一部分）自行命名，因此控制命名约定和 /dev 布局，从而设置被认为是坏事的策略。您可以在启动后移动（或重命名）DevFS 文件，或更改其权限，但您从内核的策略开始。（脚本可用于记录关机时 /dev 的状态。）目前，尚不清楚发行版将使用哪些例程，或者它们是否会使用 DevFS。毕竟，DevFS 仍然是 “实验性的”，尽管这在发布之前可能会发生变化。
虽然在内核中设置策略被认为是坏事，但 DevFS 模型的许多优点使 Linus 相信新方法是正确的方法。正在进行工作，使 DevFS 对因其缺点而感到痛苦的管理员更加 “友好” ——其中一些可能会在 Linux 2.4 正式发布之前进入内核。
Linux 2.4 的另一个半革命性变化涉及其处理磁盘和分区的方式。以前版本的 Linux 在磁盘和分区的使用方式上受到一定的限制。与大多数其他操作系统一样，Linux 直接位于标准硬件分区方案之上。使用 fdisk 或类似的工具，您可以创建格式化为 “Linux swap” 或 “ext2” 的分区。然而，一旦这些分区就位，就很难更改。调整大小或移动分区几乎是不可能的，即使对于高级用户来说也是如此。
以前版本的 Linux 包括 “多设备”（或 “md”）驱动程序，该驱动程序允许 Linux 管理员连接分区并执行更复杂的操作以创建软件 RAID 阵列。使用此驱动程序和一些技巧，可以稍微扩展本机分区方案，但无法达到许多应用程序所需的灵活性水平。
逻辑卷管理器有能力使 Linux 世界变得更加灵活。（就像 md 驱动程序一样，其他操作系统通常无法理解 Linux 的 LVM 方案。）LVM 不是将磁盘划分为静态分区，而是允许 Linux 用户将多个物理磁盘设备连接到单个 “卷组” 中。然后可以将这些组划分为多个 “逻辑卷”。LVM 允许调整卷的大小（在某些约束条件下）和移动卷。可以动态地将更多磁盘添加到卷组中，从而实现巨大的存储容量——几乎是无限的。LVM 子系统在商业 UNIX 世界中并不新鲜；该代码部分模仿了其在 Tru64 UNIX、HPUX 和其他商业 UNIX 系统中的实现。
作为这项工作的额外好处，调整 ext2 分区大小的代码已公开发布。虽然此代码存在于用户空间中，远离内核，但它是 LVM 子系统的一个非常重要的组成部分。即使在不使用 LVM 子系统的情况下使用，它也无疑将在下一代安装程序和类似 fdisk 的实用程序中使用。
Linux 2.4 在使其适用于非常大的环境的过程中经历了几次重大和次要的挫折。硬件是造成困难的主要原因。i386 硬件（32 位且有些过时）无法轻松支持巨型文件和 64 位操作系统的其他要求。这是硬件的限制，而不是 Linux 本身的限制。随着 NT 在 i386 硬件上的日益普及，人们一直在推动在 i386 上也获得 64 位 Linux ——推动提高 Linux 可以达到的标准，以克服平台的限制，同时又不牺牲当前实现的清洁性和速度。该领域的两项重大改进非常突出：每个系统更多的用户和非常大的文件。
首先，企业迫切需要的一项功能是 32 位用户和组 ID（UID 和 GID）。在 Linux 和 UNIX 世界中，每个用户都被赋予一个唯一的数字。不幸的是，数字系统是有限的，在某些应用程序中，65,000 个用户的限制是具有约束性的（例如，像 Geocities 或 Tripod 或 ISP 这样的高容量 Web 托管站点在获得 65,000 个用户时会出现扩展问题）。Linux 2.4 将限制提高到大约 43 亿。为了比较，世界人口刚刚超过 60 亿。[几乎足够每个人在每台计算机上都拥有一个帐户！—编者注]
随着更大更好的趋势，Linux 2.4 提高了另一个上限：最大文件大小。以前版本的 Linux 会在大于 2GB 的文件上崩溃，尽管底层文件系统理论上可以处理它。虽然许多人可能不会立即看到拥有超大文件的优势，但此功能对于管理信息或媒体特别有用——想象一下将所有 MP3 文件压缩到一个方便的文件中，或将它们放入数据库中。
应该强调的是，虽然 Linux 2.4 将允许更大更好的应用程序，但开发团队的主要关注点之一始终是针对常见情况进行优化：真实用户。为此，代码经过精心设计，使其对真实用户的影响尽可能小。虽然这些功能对于需要它们的用户来说将是资产，但对于不需要它们的用户来说不会成为绊脚石。
开源开发方法的一个好处是，人们完全可以 “fork” 内核的副本并在 fork 上进行自己的开发。内核黑客经常使用这种方法，他们想暂时离开并做自己的事情，而不必密切关注其他开发。然而，事实证明，这些更改最终必须集成到 “官方” 内核中，才能得到适当的尊重和支持。虽然 fork 可以是任何类型，但 Linux 进行 fork 和合并的一个常见领域是其对处理器系列的支持。
随着 Linux 内核的最新修订，几个新的处理器系列在内核源代码中获得了特殊的地位。ia64 是近一段时间以来内核中最受关注的新增功能之一，它是未来的 Intel 处理器，据说是 i386 系列的 64 位替代品。从某种意义上说，它有点像 PPC 对 Motorola 的 m68k。此平台的硬件实际上不存在，预计多年内不会大量到达消费者手中。然而，当第一批主板和处理器下线时，Linux 将在那里。在许多方面，这证明了 Linux 在操作系统市场中更大的作用，因为之前所有的 Linux 端口都是在硬件和替代操作系统已经可用之后完成的。
SuperH 是 Pocket PC（又名 Windows CE）机器中使用的嵌入式处理器，也是 “受 Linux 支持” 阵营的另一个新增成员。在 WinCE 硬件上支持 Linux 具有讽刺意味，许多用户对此不禁窃笑。同样，此端口仍处于早期阶段，但开发人员正在稳步推进。
在计算领域的另一端，S/390 也将获得一个端口。S/390 是 IBM 大型机系列的最新一代，可能是 Linux 已知运行的最大硬件种类。大部分端口是由 IBM 完成的；就其本身而言，这对于 Linux 社区来说是另一个第一。
虽然 Linux 确实在官方内核源代码发行版中支持所有这些新处理器，但这些端口不一定已准备好投入使用。此外，针对这些处理器中的任何一个的预编译发行版可能离 “普通用户” 阶段还很遥远。
虽然我可能不应该承认，但我认识许多从未费心将其内核升级到 Linux 2.2 的系统管理员。即使 Linux 2.2 包含一个完全重写的网络层，但费心将其旧的（2.0 时代）脚本更新到 2.2 命令集对某些人来说是令人生畏的。话虽如此，Linux 2.4 再次重写了整个网络层，并引入了一个全新的接口：iptables。但是那些不想再次升级的人呢？这一次，Linux 2.4 包含用于 2.0 和 2.2 时代工具的兼容性模块。由于兼容性工具降低了入门门槛，因此希望此版本的 Linux 内核将比以前的版本更容易实现。
Linux 2.4 网络层并非白白重写。网络地址转换 (NAT) 和防火墙操作在其操作中变得更加灵活，并拆分为单独的模块。借助这些模块，Linux 2.4 系统变得几乎与当今的商业路由硬件一样强大和灵活。当然，要使用新内核的真正出色的功能，您必须使用 “真正的” iptables 接口，而不是提供的任何兼容性接口。
虽然新的灵活性可能足以说服核心网络人员升级，但 2.4 Linux 内核还包括针对网络层的更通用的修复和加速。David Miller 和其他网络专家一直在努力确保 Linux 2.4 更有效地与其他操作系统对话。网络层和 TCP/IP 堆栈已被重写，以便在多处理器机器上更具可扩展性。现在编写网络设备驱动程序是为了使其更稳定并消除基础架构中一些可能的竞争条件。这些更改进一步建立在 Linux 2.2 开发周期中在 Linux 网络方面完成的伟大工作的基础上。
Linux 2.2 在内核中首次正式支持帧缓冲图形设备；Linux 2.4 还识别用于内核级控制图形硬件的新接口。随着直接渲染管理器 (DRM) 的引入，出现了一个系统来控制多个要求苛刻的视频进程。Linux 2.4 没有成为完整的视频驱动程序本身（此类事情最好留在用户空间中），而是通过提供内核接口来控制和同步对图形设备的访问，从而使用户空间视频更加稳定（和安全）。受支持的程序（如 Xfree4.x）将在需要硬件资源时与此接口对话。内核将知道何时多个程序尝试同时访问视频结构，并将保存状态或执行任何必要的操作以确保它们不冲突。由于受支持的程序将无法向图形硬件发送冲突的请求，因此这些冲突将无法导致崩溃。此新功能主要面向高级加速硬件，但低端硬件也可能从新的资源分配例程中受益。
Linux 2.4 的一个主要改进领域是它支持的设备类型数量。我已经在之前的文章中写了关于 Linux 2.4 对 USB、ISA 即插即用和 PC Card 设备的支持。然而，如果不提及对火线和 I2O（智能输入/输出）设备（PC 硬件市场的两个相对较新的补充）的支持，这张图景就不完整。
火线，IEEE 1394，是一种高速外部总线系统，其概念类似于 USB。（您可能还会听到它被称为索尼的名称：i.Link。）与 USB 不同，火线在同一总线上支持多台计算机，并且传输速度高于 USB。由于可用带宽高，火线已被证明最适用于数字（视频）摄像机和需要快速传输大量数据的类似设备。应该注意的是，虽然 Linux 下支持底层总线，但并非所有硬件芯片组和设备都已受支持。随着时间的推移和更多硬件的上市，这种支持将得到改善。
I2O 是一种新型 I/O 子系统，除了高速数据传输外，还具有操作系统独立性。这意味着，从理论上讲，一个驱动程序保证适用于所有特定类型的设备，而与供应商或设备内部的实际工作方式无关。对我们来说不幸的是，到目前为止制造的 I2O 设备相对较少，并且内核支持仍然有些不完整。
虽然火线和 I2O 对 Linux 领域来说相对较新，并且这些总线类型的硬件实际上很少存在，但开源雪球正在滚动，并且随着这些设备变得越来越普遍，对这些设备类型的支持将得到改善。
电子邮件：jpranevich@lycos.com
