理解和使用Linux的硬件抽象层HAL

理解和使用Linux的硬件抽象层HAL作者：刘旭晖 Raymond转载请注明出处Email：colorant@163.comBLOG：/colorant/说来惭愧，基于ARM平台的驱动做了这么长时间了，以前一直在kernel里面忙活，很少了解上层应用相关的发展，也没有接触过HAL和 DBUS。因为最近做的项目上层是基于X86的软件框架来做，和以前的模式也有较大的变化，借此机会也想了解一下上层应用和底层驱动的配合和以前有什么不同，所以很自然的就需要了解Hal。记录一下自己的学习理解吧。本人的能力和测试时间有限，可能下文中有些理解、分析不一定准确，欢迎联系指正。1 相关说明1.1 网站资源HAL的官方网址：/wiki/Software/hal/os/project/tamarack/hal_re.html solaris系统上的同志写的一篇分析HAL框架原理的文章。很好，就是版本稍微有点旧/~d ... ndling-OLS-2006.pdf 2006年Linux研讨会上，Hal的作者David Zeuthen所提交的Paper。顺便提一下，研讨会的网址是：/有不少Paper看起来真的很不错啊，很有兴趣！今年的会议有好多Paper我都等不及想看看了。1.2 工作环境Hal本身对环境的要求是：Linux kernel 2.6.17 (or later)util-linux 2.12r (or later)udev 089 (or later)dbus 0.61 (or later)glib 2.6.0 (or later)我想，关键是内核了，低于这个版本的内核就不用玩了 8 )至于我的环境：硬件平台：基于ARM的嵌入式板子软件环境：Linux 2.6.21 ，自制文件系统 Dbus 1.0.2 Hal 0.5.102 理解HAL2.1 什么是HAL说实话，这部分很多人写过，不过为了文章的完备性，我还是从我理解的侧重点再写一下。首先HAL不是2001太空漫游系列里的那台超级电脑8 )HAL是Hardware Abstraction Layer即硬件抽象层的首字母缩写，以下来源于Hal Spec的框图很好的说明了它的组成部分：它是一个位于操作系统和驱动程序之上，运行在用户空间中的服务程序。它的目的是对上层应用提供一个统一的简单的查询硬件设备的接口。它所谓的抽象，基本上也就仅限于这一功能，它通常并不提供对硬件的实际操作，对硬件的操作，还是由应用程序来完成。细化来说，除了提供标准的硬件查询接口，它甚至并不考虑如何对硬件进行配置，这不是它要完成的工作，但它确实提供了存储硬件配置相关信息的空间。下面我们会说到，那被称为属性。所以，简单的说，你可以把HAL理解为：一堆的硬件列表以及他们的相关属性的集合。那么，这一堆硬件列表能有什么用呢？应该说，它简化了应用的查询逻辑，把这一部分的复杂性转移到了应用程序之外，由HAL统一处理，其次，按作者的期望，当一些库函数也开始使用HAL的时候，应用程序甚至可以把对不同硬件的实际操作的复杂性也交给库函数来自动处理。2.2 HAL的组成框架按照上面的框图，首先是HAL daemon，HAL的服务进程。其次是硬件信息文件，后缀fdi，再有是Callout和Addons，这些是HAL针对不同硬件进行额外的处理工作所需的一些可执行文件或脚本。在Hal内部，每个硬件(具体的或抽象的)都是由一个Device Object设备对象来表示。每个设备对象会包括以下几个概念的组成部分：UDI: Unique Device Identifer 每个设备对象的唯一标识符，它是根据BUS信息得到的，它的目标是保证设备的唯一性，同时在一个可移除设备多次插入拔出过程中保持相同的值。Property ：属性，是一个key/value pair。每个属性由一个键和一个键值组成，用来存储设备对象相关的各种信息。Method ：方法是用来读取设置属性，或提供某些特定操作。Interface ：这个更多的是DBUS的概念。属性和方法被分类到不同的Interface中。2.3 HAL硬件信息的来源HAL中设备对象的相关信息来源主要有以下几种：通过Sysfs得到，有相当一部分的属性是通过这种方式得到的，比如UDI，设备的厂商，设备的父节点，设备的总线类型，硬盘的UUID啊等等。通过Probe探测得到，有些设备，例如一个Camera设备，它支持哪些数据格式啊之类的信息，对应用层程序也是有意义的，但是只是通过Sysfs接口并不能得到，而通过Linux V4L2子系统所定义的的一些标准接口函数，通过IOCTL可以得到这些信息。通常这是由HAL服务进程调用相应的callout去probe得到。类似还有很多子系统都定义了自己标准的接口函数，这为HAL获取进一步的设备