获得 shell 提示符仅仅是试验的开始，而不是结束。现在我们必须让其他实用程序工作，以便我们能够调试更多的系统，并使其成为一个真正可用的类 UNIX 系统。

我安排 Brian Nelson 负责移植更多的实用程序，从 MCC 1.0+ 发行版的 “fileutils” 和 “shellutils” 子集开始。与此同时，我意识到更好的调试工具将加快调试过程，我开始考虑为 gdb 实现某种远程调试器支持。我的第一个实现是在 ISP CPU 模拟器下。这样做的原因是，我可以向 ISP 添加代码来检查和修改机器的状态，并与调试器通信，而无需在内核本身中编写断点处理程序。

GDB 内置了远程调试协议；我所需要做的就是向 ISP 添加代码以响应 gdb 命令，并对模拟机器状态进行编码以供 GDB 使用。让这一切工作只用了几天的时间。

当这一切发生时，我们意识到 Linux/Alpha 正在变成一个严肃的项目，我们可以在设备驱动程序方面获得一些帮助。虽然控制台回调驱动程序在启动和运行方面表现出色，但它们不足以支持生产系统。我们从 Digital UNIX 团队招募了 Jay Estabrook 来担任这个职位，事实证明他是我们团队极其宝贵的补充。在他加入团队的头两个星期内，他为 DEC 2000 AXP (“Jensen”) 系列的 Linux 开发了原生文本模式 VGA 驱动程序和原生键盘驱动程序。

将设备驱动程序移植到 Linux/Alpha 带来了一些有趣的挑战。幸运的是，许多问题只需要解决一次，结果将适用于许多不同的驱动程序。

Alpha CPU 没有 I/O 总线访问的概念；没有与 Intel inb/outb 指令等效的 Alpha 指令用于与 I/O 总线通信。为了实现基于 PCI 或 EISA 的 Alpha 系统，需要某种 “胶合” 逻辑来将 Alpha 加载/存储访问转换为 I/O 总线访问。在基于 DECchip 21064 和 21164 CPU 的系统上，这种胶合逻辑在外部芯片组（DECchip 21071 系列）中实现。在基于 DECchip 21066 的系统上，这种胶合逻辑内置于 CPU 中。这种胶合逻辑在系统物理地址空间中留出某些区域用于与 I/O 总线通信。为了执行总线访问，需要获取诸如 I/O 端口号和传输大小等信息，并将其编码为特殊的内存地址（对于不同的胶合逻辑实现，这种编码是不同的）。然后，可以从该地址加载数据或将数据存储到该地址。

中断处理在 Alpha 系统上也有所不同。在大多数基于 Intel 的系统上，总线 IRQ 和中断向量之间的映射是固定的且直接的，并且硬件直接调度到与特定 IRQ 关联的中断向量。在 Alpha 上，所有中断都由 PALcode 调度。Digital UNIX PALcode 将所有设备中断向量化到一个例程。此例程的参数之一是一个数字（称为 “SCB 向量”，原因我无需在此赘述），指示接收到哪个中断。不幸的是，总线 IRQ 和 SCB 偏移量之间的映射在所有平台上都不相同。这意味着我们需要中断处理路径中的额外代码来将 SCB 向量映射回 IRQ 号。事实上，不同平台有不同版本的映射例程。

事实证明，许多 Intel Linux 设备驱动程序依赖于 BIOS 在操作系统看到设备之前将设备置于已知状态。当我们调试键盘驱动程序（以及后来的 SCSI 驱动程序）的中断处理时，我们发现了这一点。显然，Intel 机器上的中断控制器由 BIOS 初始化，以触发 IRQ 线的 转换（边沿触发），而不是 IRQ 线的 状态（电平触发）。在我们向 CPU 初始化例程添加代码以正确设置中断控制器之前，我们遇到了无休止的 “伪” 中断问题。

虽然我们早期决定使用 SRM 控制台对于启动项目来说是好的，但事实证明 SRM 控制台不是 Linux 的最佳选择。首先，SRM 控制台非常耗内存，因为它必须实现 OpenVMS 和 Digital UNIX 所需的众多功能。Linux 不需要其中的许多功能。其次，更严重的是，SRM 控制台不是免费可再发行的。Digital 向第三方收取可观的许可费，以获得 SRM 固件的转售权，以及 Digital 或第三方销售的每个 SRM 固件副本的单位费用。虽然最终用户通常看不到这些费用，但当硬件以 Digital UNIX 或 OpenVMS 配置销售时，这些费用确实会提高硬件的价格。此外，为 Linux/Alpha 要求 SRM 控制台将给希望为 Linux 市场构建和销售 Alpha 系统的克隆供应商带来重大负担。

由于这些原因，我们决定研究开发 Linux/Alpha 的免费软件 “迷你加载器” 的可能性。迷你加载器可以比 SRM 控制台小得多，因为它只需要实现初始化系统、加载 PALcode 和加载 Linux 所必需的功能。它也可以以源代码和二进制形式自由再发行。

不幸的是，开发控制台固件的替代品是一项非同寻常的任务。幸运的是，我们得到了英国雷丁的 Digital Semiconductor 机构的 Dave Rusling 的帮助。Dave 在 Digital Semiconductor 生产的评估板上的低级硬件支持方面拥有丰富的经验，并且他已经在 PCI 支持领域为 Linux/Alpha 项目做了大量工作。他欣然接受了开发迷你加载器的任务。

迷你加载器由系统初始化代码、符合 OSF 的 PALcode 库、引导加载程序和控制台回调例程组成。它向引导加载程序和内核呈现一个类似于 SRM 控制台中看到的界面，但功能有所简化。迷你加载器仅实现 Linux 使用的那些 SRM 功能和回调。截至本文撰写之时，迷你加载器已成功在 Digital Semiconductor 的几个评估板型号上以及低成本 AXPpci/33 “NoName” 主板和高性能 “Cabriolet” 主板上启动了 Linux。

当我们致力于 32 位移植时，Linus 正在赫尔辛基努力进行他的 64 位 Alpha 移植。我们知道，我们迟早会想要切换到使用他的代码库，以便与 Linux 社区的其余部分保持同步。主要问题是 何时 我们会进行切换。我们的移植版本更早地展示了更多功能（例如，设备支持、网络、实用程序），但 Linus 正在快速赶上。我们决定继续致力于 32 位移植版本以用于演示目的，同时跟踪 Linus 的进展，并且当这样做会产生功能大致相当的系统时，我们将切换到 Linus 的代码库。

这一点出现在 1995 年 3 月，当时 Linus 在 linux-alpha 邮件列表中发布了一条消息，主题为 “ftp.cs.helsinki.fi 上的自托管 linux”。虽然我们自己的主要目标之一是拥有一个自托管的 Linux/Alpha 系统，但由于在我们的交叉开发环境中移植 GNU 编译器套件的巨大复杂性，我们一直未能实现它。Linus 非常巧妙地通过使其 Linux/Alpha 系统调用与其 Digital UNIX 对应物兼容，从而绕过了整个交叉构建问题。因此，他可以通过在他的 Linux/Alpha 系统上运行来自他的 Digital UNIX 系统的编译器来轻松实现自托管。

虽然这种自托管环境不符合我们 100% 免费软件的标准，但它是一个有用的起点。与其在一个脾气暴躁的交叉开发环境中构建 GNU 工具并在一个不成熟的操作系统上测试它们，不如我们在 Digital UNIX 系统上原型化和调试我们的 整个 开发环境。当我们对其功能感到满意时，我们可以将其复制到 Linux/Alpha 系统，并合理地确信它可以工作。事实上，这正是我们组装我们在 1995 年 5 月在 DECUS 上展出的自托管演示的方式（“DECUS 上的 Linux”，Linux Journal 第 15 期，1995 年 7 月）。

正如任何 Linux 发行版的创建者都可以告诉你的那样，操作系统不仅仅是一个内核。为了能够免费向 Linux 社区提供 Digital 的所有 Linux/Alpha 贡献，我们必然不得不限制我们在该项目中投入的资金。截至本文撰写之时，Digital 正在资助三名全职工程师、一名兼职产品经理、一名兼职技术作家和几台借用的 Alpha 系统（包括 Linus 一直使用的 Alpha 系统）。在我的 Linux/Alpha 项目计划大纲中，我指出 Linux 的独特之处在于我们可以用如此有限的资源来完成该项目。鉴于 Linux 的历史，我推断，一旦 Linux/Alpha 代码可用，网络上的开发人员将添加功能和修复程序。我的预测令人愉快地成真了。Digital 内外的一些人在不花费 Digital 任何成本的情况下为该项目做出了重大贡献。结果对 Digital 和整个 Linux 社区都带来了巨大的好处。

当然，Linus Torvald 本人的贡献是传奇性的。我在这里提到他，是因为如果没有他的不知疲倦的工作，该项目将会走向不同的方向，并且可能不会像今天这样成功（Linus，如果你正在阅读本文，我们 可以 在版本之间留出一些喘息空间。至少让我完成 编译 一个版本，然后再发布下一个版本！）

Linux/Alpha 项目的另一位主要拥护者和支持者是亚利桑那大学的 David Mosberger-Tang。他实际上是他的街区第一个拥有基于 Alpha 的 AXPpci/33 主板的人，并且他提供了所有初始补丁，以使 32 位和 64 位内核都可以在该平台上运行。他也是一个宝贵的资源和第二双眼睛，可以协助解决棘手的问题。此外，他还移植了许多系统和实用程序包，这些包原本会花费我们几天甚至几周的时间才能在我们的业余（哈！）时间完成。

有人说 “任何足够先进的技术都与精心策划的演示无法区分”，这当然可以用来形容我们上演的 DECUS 演示。虽然该工具集能够构建和链接内核，但 64 位 C 运行时库还不够稳定，无法构建用户实用程序。修复这个问题与许多其他事情一起列在我们的 “待办事项” 清单上，但事实证明我们不必这样做。在我们向 Digital 的 FTP 区域发布 64 位开发工具后不久，俄亥俄州立大学的 Bob Manson 基于我们早期的 32 位工作发布了一个可用的 64 位库。Bob 还发布了几组有用的实用程序，同样，这将花费我们数周的时间才能抽出时间自行移植。据传他还致力于修改 gcc 以生成能够从异常中恢复的浮点代码。

在 DECUS 上展示 Linux/Alpha 之后，很明显需要某种最终用户可安装的发行版。在那时，Linux/Alpha 在某些方面类似于早期 Intel Linux：该 “系统” 由分散在不同大陆的几个 FTP 站点上的各种源代码和二进制归档文件组成。将这些碎片拼凑成一个运行的系统只有执着的黑客才愿意去做。

那时和现在的一个区别是，现在有高质量的商业 Linux 发行版（Plug-And-Play、Red Hat 和 Slackware，仅举几个例子）可以作为等效 Linux/Alpha 发行版的基础。但我们知道，这些发行版需要一段时间才能移植并获得 Linux/Alpha 的认证。为了维持在 DECUS 上建立的势头，我们需要比这更早的某种 Linux/Alpha 发行版。那时我们决定开始一个旨在过时的项目：BLADE。BLADE 代表 Basic Linux Alpha Distribution Expletive（我通过从 “LAD”（Linux Alpha Distribution 的缩写）开始，然后在 /usr/dict/words 中 grep 此组合，并使用一些结果玩首字母缩略词游戏来选择名称）。BLADE 是一个 Linux/Alpha 套件，无需构建内核或使用主机开发系统即可安装。

BLADE 旨在快速部署，并且它非常粗糙。只有一个自动安装脚本，名为 install_subset。其他发行版自动完成的许多步骤必须在 BLADE 中手动处理。但是，我们提供了完整的逐步说明，以便用户知道需要采取哪些步骤。

BLADE 的第一个版本（V0.1）以字符单元模式提供了基本功能和开发系统。没有网络、没有 GUI，并且实用程序集有限。但是，它是自托管的，并且附带内核源代码和 gnu 编译器套件。人们可以使用 BLADE 构建内核或任何所需的实用程序。事实上，我们使用 BLADE V0.1 作为 BLADE V0.2 的主要开发系统。BLADE V0.1 基于修改后的 1.2.8 内核，仅支持 AXPpci/33。

BLADE 的第二个版本（V0.2）添加了更多实用程序和网络功能。图形仍然不可用，但人们可以在字符单元模式下执行开发和基本网络（ftp、telnet、rlogin）。BLADE V0.2 也是第一个在 AXPpci/33 上支持 Linux/Alpha 迷你加载器（又名 MILO/Alpha）的版本。MILO 是一个即插即用的系统固件替代品，允许用户在不需要 SRM 控制台固件的情况下启动和运行 Linux。BLADE V0.2 还为 Digital Semiconductor 275-MHz EBPC/64 评估主板添加了内核启动盘。这是迄今为止支持 Linux 的最快系统。BLADE V0.2 也基于修改后的 1.2.8 内核。

目前正在开发 BLADE V0.3。BLADE V0.3 将基于 1.3 内核，并将添加对 X 窗口系统的支持（见下文）。它还应该支持更多系统类型。

感谢我的同事 Jay Estabrook 不懈的努力，截至本文撰写之时，X11R6 已经在 Linux/Alpha 上启动并运行。大多数标准库和客户端可执行文件都已到位。目前，只移植了 S3 服务器，并且只在少数显卡上进行了认证。目前的计划是让它成为一个示例服务器，并征求其他方（例如，XFree86 联盟）移植其他服务器。

支持多种显卡的一个主要问题与许多显卡具有的板载 ROM BIOS 有关。此 BIOS 通常包含初始化显卡和设置视频模式的代码。不幸的是，此 BIOS 几乎总是用 80x86 汇编代码编写的。要在 Alpha 系统上执行它，需要一个 Intel 执行引擎。我们正在研究几种策略，以源代码形式将此功能作为 MILO/Alpha 的一部分提供，并且有传言称我们的老朋友 David Mosberger-Tang 在这方面取得了良好的进展。

当我写这篇文章时，Linux/Alpha 正在纽约市的 UNIX Expo 上展示其所有 X 窗口的辉煌。我们已经移植了免费网络浏览器 chimera，这些系统可用于在网络上冲浪以及通过 rlogin、telnet 和 ftp 连接到 Internet 上的远程系统。事实上，在安装日，一些来自未连接网络的展位的几个人过来使用这些系统从他们的家庭系统检索遗忘的文件。这包括可悲的是我本人。我们需要连接到我们的 PC64 系统上的串行端口以使用 ROM 调试监视器，但是另一个系统上的 Linux/Alpha 版本没有 kermit、cu、tip 或任何其他终端仿真或串行连接程序。没问题：我 ftp 到了 David Mosberger-Tang 在 ftp.azstarnet.com 的存档，并检索了 Linux/Alpha 版本的 kermit。我们在几分钟内就恢复了业务。

简而言之，Linux/Alpha 开始感觉像一个真正的 Linux 系统！

尽管我们取得了巨大的进步，但 Linux/Alpha 仍有许多工作要做

总而言之，我们对未来感到兴奋。Linux/Alpha，即使在其相对原始的状态下，也感觉像一个真正的 Linux 系统。解决上述领域只会使其变得更好！