硬件抽象层

定义

硬件抽象层(Hardware Abstraction Layer，简称 HAL)是位于操作系统内核与硬件电路之间的接口层，其目的在于将硬件抽象化。它隐藏了特定平台的硬件接口细节，为操作系统提供虚拟硬件平台，使其具有硬件无关性，可在多种平台上进行移植^[1][2]。

硬件抽象层是一个编程层，允许操作系统在逻辑层而不是在硬件层与硬件设备交互。操作系统核心或者硬件驱动程序都可以调用它；无论哪种情况，调用程序都不必了解硬件的具体设计细节，只需要给出抽象层所需的参数即可^[3]。也有研究者把它描述为位于硬件环境和操作系统之间的一种特殊软件，屏蔽底层硬件环境的多样性并提供符合一定规范的接口供上层模块调用^[4]。

在微软的[ [Windows]] 内核体系中，硬件抽象层被定义为“将硬件差别与操作系统其他层相隔离的一薄层软件”，它通过让多种不同硬件在操作系统的其他部分看来是同一种虚拟机的方式实现这层隔离^[5]。

原理

硬件抽象层的基本思路是在纵向结构上做分层：从操作系统中划出一个可以直接与硬件通讯的层次，下层通过 API 的形式向上层提供服务，上层进行硬件操作时不需要了解设备的具体细节，从而降低系统理解和开发的复杂度。采用这种分层方法的好处包括节省成本、易于理解、易于扩展和易于排错^[5]。

与分层相配套的是模块化与对象化。模块化的特点是把接口和实现分离，把具体功能块隐藏在抽象接口背后，使模块之间的依赖关系仅限定于接口；模块之间是相互独立的关系，而不是层次之间的相互依赖关系。对象化则把数据与其上的操作封装在对象实体中，外界只能通过消息间接访问^[1]。

在实现上，有的系统会把硬件抽象层进一步细化为若干子层次，各子层之间定义统一的接口调用。这些接口采用 C/C++ 语言编码，下层功能实现需要按照与上层确定的接口规范进行；上下层之间的接口使用宏定义方式，宏定义在预编译时替换，没有执行时的性能损失，片级初始化、板级初始化和系统级初始化基本上都利用了宏定义的这一特点^[2]。

从软件结构上看，硬件抽象层在可移植操作系统中的位置可以表示为如下的层次关系：

flowchart TB

A[应用程序与应用框架] --> B[操作系统内核]

B --> C[设备驱动程序]

B --> D[硬件抽象层 HAL]

C --> D

D --> E[处理器、中断控制器、总线等硬件]

发展历程

硬件抽象层技术最初由微软提出，目的是确保 Windows NT 的稳定性和兼容性。针对此前 Windows 系列操作系统经常出现的系统死机或崩溃等现象，微软认为程序设计直接与硬件通信是造成系统不稳定的主要原因；在此基础上，Windows NT 取消了对硬件的直接访问，首先提出硬件抽象层的概念^[6]。

随后，这一设计思路被一些嵌入式操作系统参考，其系统内核被分成两层：上层称为内核(Kernel)，底层则称为硬件抽象层。在嵌入式操作系统中，HAL 独立于内核；对操作系统和应用软件而言，HAL 是对底层架构的抽象。由于 HAL 层代码与底层硬件设备紧密相关，因此也可以把硬件抽象层理解为所有依赖于底层硬件的软件^[5]。

在 Windows 的实现中，硬件抽象层是一个可加载的核心态模块，文件名为 hal.dll，为运行其上的硬件平台提供低级接口。它向内核、设备驱动程序和执行体的其他部分隐藏与硬件有关的细节，例如 I/O 接口、中断控制器以及多处理机通信机制等体系结构专用或依赖计算机平台的函数；设备驱动程序不直接操作硬件，而是调用 HAL 功能与硬件交互^[7]。

硬件抽象层的实现方式此后继续演化。在 Android 系统中，8.0 之前的 HAL 以共享库模块(.so 文件)的形式由系统动态加载，框架与 HAL 之间没有强制的标准交互方式^[8]。Android 8.0 起引入了用 HIDL 编写 HAL 的新架构，要求设备支持以 HIDL 描述的 HAL，并区分绑定式与直通式两类；Android 11 又加入用 AIDL 编写的 HAL^[9]。

应用

硬件抽象层最典型的应用是在操作系统中隔离硬件差异。以 Windows 为例，同一体系结构内接口的实现可能因平台系统而异，部分内核接口实际是在 HAL 中实现的；[ [Windows 2000]] 和 Windows XP 可以在不同机器上调用那些独立于体系结构的接口，其语义保持不变^[7]。

在嵌入式领域，HAL 被用于构建易于移植的硬件平台，把与硬件相关和硬件无关的两部分程序代码隔离开，为上层软件提供已屏蔽硬件差异的接口^[2]。有研究把 HAL 用于实时数据处理与图形显示，使操作系统不必直接与硬件环境通信^[4]。

在移动系统上，Android 的 HAL 为硬件供应商定义了标准接口，供应商据此实现较低层级的设备专属功能，而不影响或修改较高层级的代码。开发者必须为产品所提供的特定硬件实现相应的 HAL 和驱动程序，HAL 实现通常内置于共享库模块(.so 文件)中^[10]。为保证结构可预测，各硬件专属 HAL 接口都要具备在 hardware.h 中定义的一组属性，接口由模块和设备两个组件构成：模块以共享库形式存放实现，包含版本、名称、作者等元数据；设备则抽象产品实际硬件，例如一个音频模块可以包含主音频设备、USB 音频设备或蓝牙 A2DP 音频设备^[11]。

硬件抽象层还影响到软硬件的测试组织方式。由于双方都可分别基于 HAL 完成测试，软硬件测试工作的并行进行成为可能^[1]。在针对可移植操作系统的验证中，测试程序在用户态发出内核请求，内核再向 HAL 发出请求，由 HAL 完成相应功能并回传状态信息^[12]。

局限

硬件抽象层并不能把所有硬件细节完全隔离。有技术分析指出，HAL 并不完全位于内核之下，因为内核在某些地方仍然直接与硬件对话，同时 HAL 的许多功能也依赖内核，因此二者通常以匹配的集合形式出现^[13]。

这层抽象也给验证带来困难。以 Windows NT 为例，传统方法是让硬件兼容性测试程序在用户态发出内核请求，内核再向 HAL 发出请求。该做法的一个主要问题是，测试程序与内核之间、内核与 HAL 之间、HAL 与硬件之间的抽象层级差别很大，内核功能与硬件动作之间并不存在整齐的一一对应关系：一个 I/O 请求可能起初是文件 I/O 请求，然后被 HAL 转成若干个 DMA 请求。使用这种传统方法测试和验证 HAL 容易出错、耗时且不够彻底^[12]。

从工程实践看，HAL 还带来额外的复杂度与维护成本。微软的驱动文档并不建议开发者自行编写 HAL，如需访问硬件，应使用 HAL 库提供的例程^[14]。Android 方面，早期 HAL 从未提供严格的稳定性保证，大部分系统接口定义在硬件头文件目录下，只有大致的版本控制和大致稳定的 ABI，部分子系统还存在非标准接口^[15]。

抽象层的边界也可能随平台变化。在 Windows 中，HAL 的功能和实现方式会因处理器体系结构和机器配置不同而不同，例如是否具备兼容 ACPI 的 BIOS、是否存在 APIC、是否为多处理器，都会影响安装时选择哪一份 HAL；从 Windows 10 版本 2004 起，HAL 被合并或静态链接进 ntoskrnl.exe，对应的 DLL 只作为向后兼容的存根保留^[16]。

参见

• 驱动程序 —— 位于操作系统与具体硬件之间、常通过硬件抽象层与硬件交互的软件组件。

• 操作系统内核 —— 硬件抽象层通常位于其与硬件电路之间，并为其提供与平台无关的接口。

• 嵌入式操作系统 —— 较早参考 HAL 分层思路、把内核分为内核与硬件抽象层两层的系统类型。

• 可移植性 —— 硬件抽象层所要解决的核心问题，使同一系统能在多种硬件平台上运行。

• 应用程序接口 —— 硬件抽象层通过接口规范向上层提供服务所采用的形式。