心的距離

转载时请注明出处和作者联系方式：http://blog.csdn.net/absurd

作者联系方式：李先静<xianjimli at hotmail dot com>

更新时间：2007-5-3

HAL是Hardware Abstraction Layer的首字母缩写。我最早是在Winnt 3.5的帮助中知道这个名词的，对帮助文档中的说法我比较认同，所以一直对它抱有好感。不过Windows下的HAL和Linux下的HAL两者所指并非相同之物：

Windows下的HAL：位于操作系统的最底层，直接操作物理硬件，隔离与硬件相关的信息，为上层的操作系统和设备驱动程序提供一个统一的接口，起到对硬件的抽象作用。有了HAL，编写驱动程序就容易多了，因为HAL的接口不但使用简单，而且具有更好的可移植性（没用过）。

Linux 下的HAL：至于对硬件的抽象，Linux内核早就有类似机制，只不过没有专门的名称罢了。而Linux的HAL指的并非这个，它不是位于操作系统的最底层，直接操作硬件，相反，它位于操作系统和驱动程序之上，是一个运行在用户空间中服务程序。

我们知道，Linux和所有的Unix一样，习惯用文件来抽象设备，任何设备都是一个文件，比如/dev/mouse是鼠标的设备文件。这种方法看起来不错，每个设备都有统一的形式，但使用并不那么容易，设备文件名没有什么规范，从简单的一个文件名，你无法得知它是什么设备，具有有什么特性。

结果形成这样的尴尬：有了设备和设备驱动程序，却不知道如何使用它。这些乱七八糟的设备文件，让设备的管理和应用程序的开发都变得很麻烦，所以有必要提供一个硬件抽象层，来为上层应用程序提供一个统一的接口，Linux的HAL就这样应运而生了。

但HAL并不提供诸如拍照和刻录等之类的功能，相反它只是告诉应用程序，系统中有哪些设备可用，以及这些设备的类型、特性和能力等。主要说来，它提供以下几项功能：

1.         获取指定类型的设备列表。

2.         获取/更改设备的属性值。

3.         获取设备具有的能力描述。

4.         设备插入/拔除时，通知相关应用程序。

5.         设备属性或能力变化时，通知相关应用程序。

udev创建dev下的文件结点，加载驱动程序，让设备处于可用状态。而HAL则告诉应用程序，现在有哪些设备可用，这些设备的类型、特性和能力，让应用程序知道如何使用它们。

设备的属性管理是HAL最重要任务之一，有的设备属性来源于实际的硬件，有的来源于设备信息文件(/usr/share/hal/fdi/)，有的来源其它配置信息(如/usr/share/hwdata/)。设备属性的都有标准的定义，这些属性定义是HAL的SPEC的主要内容之一，可以参考http://people.freedesktop.org/~david/hal-spec/hal-spec.html。

HAL作为一个后台服务程序运行，它的主体架构基于MVC的模型，在DBUS的帮助下，实现了异步事件通知机制。HAL的分层视图如下：

转载时请注明出处和作者联系方式：http://blog.csdn.net/absurd

作者联系方式：李先静<xianjimli at hotmail dot com>

更新时间：2007-5-3

HAL是Hardware Abstraction Layer的首字母缩写。我最早是在Winnt 3.5的帮助中知道这个名词的，对帮助文档中的说法我比较认同，所以一直对它抱有好感。不过Windows下的HAL和Linux下的HAL两者所指并非相同之物：

Windows下的HAL：位于操作系统的最底层，直接操作物理硬件，隔离与硬件相关的信息，为上层的操作系统和设备驱动程序提供一个统一的接口，起到对硬件的抽象作用。有了HAL，编写驱动程序就容易多了，因为HAL的接口不但使用简单，而且具有更好的可移植性（没用过）。

Linux 下的HAL：至于对硬件的抽象，Linux内核早就有类似机制，只不过没有专门的名称罢了。而Linux的HAL指的并非这个，它不是位于操作系统的最底层，直接操作硬件，相反，它位于操作系统和驱动程序之上，是一个运行在用户空间中服务程序。

我们知道，Linux和所有的Unix一样，习惯用文件来抽象设备，任何设备都是一个文件，比如/dev/mouse是鼠标的设备文件。这种方法看起来不错，每个设备都有统一的形式，但使用并不那么容易，设备文件名没有什么规范，从简单的一个文件名，你无法得知它是什么设备，具有有什么特性。

结果形成这样的尴尬：有了设备和设备驱动程序，却不知道如何使用它。这些乱七八糟的设备文件，让设备的管理和应用程序的开发都变得很麻烦，所以有必要提供一个硬件抽象层，来为上层应用程序提供一个统一的接口，Linux的HAL就这样应运而生了。

但HAL并不提供诸如拍照和刻录等之类的功能，相反它只是告诉应用程序，系统中有哪些设备可用，以及这些设备的类型、特性和能力等。主要说来，它提供以下几项功能：

1.         获取指定类型的设备列表。

2.         获取/更改设备的属性值。

3.         获取设备具有的能力描述。

4.         设备插入/拔除时，通知相关应用程序。

5.         设备属性或能力变化时，通知相关应用程序。

udev创建dev下的文件结点，加载驱动程序，让设备处于可用状态。而HAL则告诉应用程序，现在有哪些设备可用，这些设备的类型、特性和能力，让应用程序知道如何使用它们。

设备的属性管理是HAL最重要任务之一，有的设备属性来源于实际的硬件，有的来源于设备信息文件(/usr/share/hal/fdi/)，有的来源其它配置信息(如/usr/share/hwdata/)。设备属性的都有标准的定义，这些属性定义是HAL的SPEC的主要内容之一，可以参考http://people.freedesktop.org/~david/hal-spec/hal-spec.html。

HAL作为一个后台服务程序运行，它的主体架构基于MVC的模型，在DBUS的帮助下，实现了异步事件通知机制。HAL的分层视图如下：

说明：

1.         实线箭头为主动调用，虚线箭头为事件上报。

2.         udev通过NetLink注册内核的设备事件，当有设备插入/拔除时，udev就会收到通知，它会从事件中所带参数和sysfs中的信息，加载适当的驱动程序，创建dev下的结点，让设备处于可用的状态。

3.         udev只是一个框架，它的行为完全受它的规则所控制，这些规则存放在目录/etc/udev/rules.d/中，其中90-hal.rules是用来让udev把设备插入/拔除的事件通过socket socket:/org/freedesktop/hal/udev_event转发给HAL的。

4.         HAL挂在socket:/org/freedesktop/hal/udev_event上等待事件，有事件发生时就调用函数hald_udev_data处理，它先从事件中取出主要参数，创建一个hotplug_event对象，把它放入事件队列中，然后调用hotplug_event_process_queue处理事件。

5.         函数hotplug_event_begin负责具体事件的处理，它把全部事件分为四类，并分别处理hotplug_event_begin_sysfs处理普通设备事件，hotplug_event_begin_acpi处理ACPI事件，hotplug_event_begin_apm处理APM事件，hotplug_event_begin_pmu处理PMU事件。要注意的是，后三者的事件源并非源于udev，而是在device_reprobe时触发的(osspec_device_reprobe/hotplug_reprobe_tree/hotplug_reprobe_generate_add_events/acpi_generate_add_hotplug_event)。

6.         函数hotplug_event_begin_sysfs中，如果是插入设备，则创建一个设备对象，设置设备的属性，调用相关callouts，然后放入设备列表中，并触发signal让dbus通知相关应用程序。如果是拔除设备，则调用相关callouts，然后从设备列表中删除，并触发signal让dbus通知相关应用程序。

7.         应用程序可以主动调用HAL提供的DBUS接口函数，这些函数在libhal.h中有定义。应用程序也可以注册HAL的signal，当设备变化时，HAL通过DBUS上报事件给应用程序。

8.         callout是HAL一种扩展方式，它在设备插入/拔除时执行。可以在设备信息文件中(/usr/share/hal目录)指定。

9.         addon也是HAL一种扩展方式，它与callout的不同之处在于addon往往是事件的触发者，而不是事件的消费者。HAL的事件源主要源于udev，而udev源于kernel的hotplug，然而有的设备如电源设备、磁盘设备和特殊按键等，它们并不产生hotplug事件。HAL就得不到通知，怎么办呢，addon就是用于支持新事件源的扩展方式。比如addon-acpi从/proc/acpi/event或者/var/run/acpid.socket收到事件，然后转发成HAL事件。addon-storage检测光盘或磁盘的状态，并设置设备的属性。addon-keyboard检测一些特殊按键，并触发相应事件。

access-check/ci-tracker/ck-tracker负责权限的检查，里面提到的PolicyKit/ConsoleKit不是太熟悉，有时间再看看。

简单的说，HAL就是一个设备数据库，它管理当前系统中所有的设备，你可以以多种灵活的方式去查询这些设备，可以获取指定设备的特性，可以注册设备变化事件。

说明：

1.         实线箭头为主动调用，虚线箭头为事件上报。

2.         udev通过NetLink注册内核的设备事件，当有设备插入/拔除时，udev就会收到通知，它会从事件中所带参数和sysfs中的信息，加载适当的驱动程序，创建dev下的结点，让设备处于可用的状态。

3.         udev只是一个框架，它的行为完全受它的规则所控制，这些规则存放在目录/etc/udev/rules.d/中，其中90-hal.rules是用来让udev把设备插入/拔除的事件通过socket socket:/org/freedesktop/hal/udev_event转发给HAL的。

4.         HAL挂在socket:/org/freedesktop/hal/udev_event上等待事件，有事件发生时就调用函数hald_udev_data处理，它先从事件中取出主要参数，创建一个hotplug_event对象，把它放入事件队列中，然后调用hotplug_event_process_queue处理事件。

5.         函数hotplug_event_begin负责具体事件的处理，它把全部事件分为四类，并分别处理hotplug_event_begin_sysfs处理普通设备事件，hotplug_event_begin_acpi处理ACPI事件，hotplug_event_begin_apm处理APM事件，hotplug_event_begin_pmu处理PMU事件。要注意的是，后三者的事件源并非源于udev，而是在device_reprobe时触发的(osspec_device_reprobe/hotplug_reprobe_tree/hotplug_reprobe_generate_add_events/acpi_generate_add_hotplug_event)。

6.         函数hotplug_event_begin_sysfs中，如果是插入设备，则创建一个设备对象，设置设备的属性，调用相关callouts，然后放入设备列表中，并触发signal让dbus通知相关应用程序。如果是拔除设备，则调用相关callouts，然后从设备列表中删除，并触发signal让dbus通知相关应用程序。

7.         应用程序可以主动调用HAL提供的DBUS接口函数，这些函数在libhal.h中有定义。应用程序也可以注册HAL的signal，当设备变化时，HAL通过DBUS上报事件给应用程序。

8.         callout是HAL一种扩展方式，它在设备插入/拔除时执行。可以在设备信息文件中(/usr/share/hal目录)指定。

9.         addon也是HAL一种扩展方式，它与callout的不同之处在于addon往往是事件的触发者，而不是事件的消费者。HAL的事件源主要源于udev，而udev源于kernel的hotplug，然而有的设备如电源设备、磁盘设备和特殊按键等，它们并不产生hotplug事件。HAL就得不到通知，怎么办呢，addon就是用于支持新事件源的扩展方式。比如addon-acpi从/proc/acpi/event或者/var/run/acpid.socket收到事件，然后转发成HAL事件。addon-storage检测光盘或磁盘的状态，并设置设备的属性。addon-keyboard检测一些特殊按键，并触发相应事件。

access-check/ci-tracker/ck-tracker负责权限的检查，里面提到的PolicyKit/ConsoleKit不是太熟悉，有时间再看看。

简单的说，HAL就是一个设备数据库，它管理当前系统中所有的设备，你可以以多种灵活的方式去查询这些设备，可以获取指定设备的特性，可以注册设备变化事件。