udev hal

标题: 简单介绍udevd, hald, dbusd的关系

 

如果应用程序使用了libdbus就能够接收到来自内核的有关硬件热插拔的通知，比如U盘的插入和拔出。
其中经过了怎样的过程呢。
首先，
udev通过NetLink注册内核的设备事件，当有设备插入/拔除时，udev就会收到通知，它会从事件中所带参数和sysfs中的信息，加载适当的驱动程序(也可以通过hald去运行应用程序让用户选择可用的驱动)，创建dev下的结点，让设备处于可用的状态。
接着，
dev把设备插入/拔除的事件通过socket:/org/freedesktop/hal/udev_event转发给HALD的。
然后，
HALD挂在socket:/org/freedesktop/hal/udev_event上等待事件，有事件发生时就调用相关函数处理，它先从事件中取出主要参数，创建一个hotplug_event对象，把它放入事件队列中，创建一个设备对象，设置设备的属性，调用相关callouts，然后放入设备列表中，并触发signal让dbus通知相关应用程序。如果是拔除设备，则调用相关callouts，然后从设备列表中删除，并触发signal让 dbus通知相关应用程序。

Udev 基本工作原理  
  Udev相关的文章很多，本文的主要目的不是提供一个完整的教学文档，对其使用，只是给出网上现有的主要资源。着重分析其基本工作原理连同在使用中碰到的一些README文档没有明确说明的问题。
1         基本概念
udev文档系统是针对2.6内核，提供一个基于用户空间的动态设备节点管理和命名的解决方案，网上关于为什么要使用udev文档系统，udev文档系统和devfs文档系统的比较，等等的文章已很多了，假如您想了解这方面的内容，请直接搜索相关的关键字。
udev的官方网址：
http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html
src code的下载地址：
http://www.us.kernel.org/pub/linux/utils/kernel/hotplug/
此外，关于udev的rules规则的撰写，网上也有很多文章，假如要获得最准确的版本，能够在src code的代码树里找到writing_udev_rules的帮助文档，这个文档其实没有逐条介绍rules的任何关键字，能够结合man udev 和 udev自带的一些rules文档来理解如何撰写您所需要的规则文档。
2         安装和启动
2.1        安装
Udev的代码树里的版本很多，我下载的最新的版本是udev-117，配合2.6.21版本的内核能够正常使用。网上很多文章介绍的可能都是稍微早期一些的版本，有些步骤包括udev的README文档似乎描述的不是很准确。
基本上这个版本的udev需要注意的是，安装时只需要udevd，udevadm两个文档，其他必需的包括udevtrigger等只是udevadm的一个符号链接。udevstart不是必需的。当然Udev.conf等配置文档还是相同。
2.2        启动
您能够在启动脚本中用udevd –d 参数启动udev文档系统的守护进程，然后使用udevtrigger将buildin的设备驱动的节点创建出来，以后模块插入移除时节点的管理会自动处理。
能够正常加载udev的前提，基本包括如下操作：
       配置路径变量
      加载sysfs文档系统
      加载一个基于ram的可写的/dev目录（其实，只要提供一个可写的目录即可，目录路径本身也是能够配置的）
    /dev目录下需要有已创建好的 console节点和null节点
脚本类似：
# Set the path
PATH=/bin:/sbin:/usr/bin:/usr/sbin
export PATH
# mount proc and devpts filesystem
/bin/mount -a
mknod /dev/console c 5 1
mknod /dev/null c 1 3
/sbin/udevd -d
/sbin/udevtrigger
Mount使用的fstab文档类似：
none                    /tmp                    ramfs   defaults        0 0
udev                    /dev                    ramfs   defaults        0 0
none                    /proc                   proc    defaults        0 0
sysfs                   /sys                    sysfs   defaults        0 0
当然，您的系统上可能还会需要预先创建一些其他的设备节点，比如串口的ttySx 才能正常启动shell，完成以上脚本的执行，那就要看具体情况了。
3         使用中的一些问题的思考
3.1        关于规则的多次匹配
帮助文档中说一个设备能够被多条规则多次匹配，但是，需要明确的一点是：
多次匹配只能添加多个Symlink，不能创建多个Name：
例如：
KERNEL=="mtdblock4", NAME+="mtdbb4"
KERNEL=="mtdblock4", NAME+="%k"
就只会创建 /dev/mtdbb4 而不会创建/dev/mtdblock4
而类似：
KERNEL=="mtdblock4", NAME+="mtdbb4"
KERNEL=="mtdblock4", SYMLINK+="mtdbb4link"
是能够正常工作的。
3.2        关于udev.conf的语法
可能大家会发现，似乎没有什么周详文档描述udev.conf的写法，实际上从udevd的代码里能够看出：
udev.conf文档里面只会解析这三个参数：
udev_root 定义udev的目录路径
udev_rules 定义udev的规则文档的目录路径
udev_log 定义log的级别
也许以后会添加一些别的配置参数？
4         基本工作原理方面的问题
这部分主要是分析了一下udev的source code，对一些自己关心的问题的理解
4.1        Udevd如何获取内核的这些模块动态变化的信息
设备节点的创建，是通过sysfs接口分析dev文档取得设备节点号，这个很显而易见。那么udevd是通过什么机制来得知内核里模块的变化情况，如何得知设备的插入移除情况呢？当然是通过hotplug机制了，那hotplug又是怎么实现的？或说内核是如何通知用户空间一个事件的发生的呢？
答案是通过netlink socket通讯，在内核和用户空间之间传递信息。
内核调用kobject_uevent函数发送netlink message给用户空间，这部分工作通常无需驱动去自己处理，在统一设备模型里面，在子系统这一层面，已将这部分代码处理好了，包括在设备对应的特定的Kobject创建和移除的时候都会发送相应add和remove消息，当然前提是您在内核中配置了hotplug的支持。
Netlink socket作为一种内核和用户空间的通信方式，不但仅用在hotplug机制中，同样还应用在其他很多真正和网络相关的内核子系统中。
Udevd通过标准的socket机制，创建socket连接来获取内核广播的uevent事件 并解析这些uevent事件。
4.2        Udevd如何监控规则文档的变更
假如内核版本足够新的话，在规则文档发生变化的时候，udev也能够自动的重新应用这些规则，这得益于内核的inotify机制， inotify是一种文档系统的变化通知机制，如文档增加、删除等事件能够立即让用户态得知。
在udevd中，对inotify和udev的netlink socket文档描述符都进行了select的等待操作。有事件发生以后再进一步处理。
4.3        Udevtrigger的工作机制？
运行udevd以后，使用udevtrigger的时候，会把内核中已存在的设备的节点创建出来，那么他是怎么做到这一点的？分析udevtrigger的代码能够看出：
udevtrigger通过向/sysfs 文档系统下现有设备的uevent节点写"add"字符串，从而触发uevent事件，使得udevd能够接收到这些事件，并创建buildin的设备驱动的设备节点连同任何已insmod的模块的设备节点。
所以，我们也能够手工用命令行来模拟这一过程：
/ # echo "add" > /sys/block/mtdblock2/uevent
/ #
/ # UEVENT[178.415520] add      /block/mtdblock2 (block)
但是，进一步看代码，您会发现，实际上，不管您往uevent里面写什么，都会触发add事件，这个从kernel内部对uevent属性的实现函数能够看出来，默认的实现是：
static ssize_t store_uevent(struct device *dev, struct device_attribute *attr,
                         const char *buf, size_t count)
{
       kobject_uevent(&dev->kobj, KOBJ_ADD);
       return count;
}
所以不管写的内容是什么，都是触发add操作，真遗憾，我还想通过这个属性实验remove的操作。 不知道这样限制的原因是什么。
而udevstart的实现方式和udevtrigger就不同了，他基本上是重复实现了udevd里面的机制，通过遍历sysfs，自己完成设备节点的创建，不通过udevd来完成。
4.4        其他
      udevd创建每一个节点的时候，都会fork出一个新的进程来单独完成这个节点的创建工作。
      Uevent_seqnum 用来标识当前的uevent事件的序号（已产生了多少uevent事件），您能够通过如下操作来查看：
$ cat /sys/kernel/uevent_seqnum
2673

 

 

   本文主要解决的问题是:

1.     udev创建设备文件需要事先有设备驱动,而Linux内核默认在打开设备文件的时候加载驱动?那么这个先有鸡还是先有鸡蛋的问题是如何解决的?

2.     udev在设计上不是应用在打开设备时候加载设备驱动的,可是start_udev这个tools却能在系统启动的时候加载已经有的设备的驱动并创建其设备文件,其中的原理是?

 

关于udev的其他一些知识比如说具体应用,rule编写,这里介绍一些网站:

Udev的主网站(英文):

    http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html

对应的中文翻译:

    FQA: 王旭 http://gnawux.blogchina.com

    Primer: http://hi.baidu.com/chenzhuoyou/blog/item/fb2f4708bc27e7970a7b8237.html

       panjet写的udev介绍: udev轻松上路

        www.linuxforum.net/forum >> Linux 高级应用  >> Linux 嵌入技术

 

1.    一些准备知识

1.1  Sysfs

    Sysfs是如何知道当前系统中的设备以及对应的设备号的呢? Sysfs发现设备是通过kernel启动时候系统初始化进行设备枚举发现的,而对应的设备号就是由对应的驱动注册的,这些驱动即可以是包含在内核里的也可以是模块的.在驱动没有加载前,系统是能通过VID和POD(Vendor ID/ Product ID)认识设备,但是不能驱动设备的.

    现在udevd(守护进程)就能使用驱动注册的设备号信息来创建设备文件了.

 

1.2  Udev Bootscript

    CLFS中提供是s10udev这个 initscript来在Linux启动的时候创建设备.在我看来和start_udev这个tools工具是一样的,这个工具本身也就是一个shell script.

    首先取消掉默认的uneven handler: /sbin/hotplug,因为kernel不再需要这个hotplug了,udevd将通过netlink socket开监听uevents.然后将在/dev中创建一些静态的设备文件节点,因为这些设备有些不被udev支持,有些又是运行udev的必然前提.(这边要区别开为内核能正常启动而创建的null和console,目的不同)

 

1.3  Device Node Create

    这边具体讲解udevd是如何通过sys来获得设备的大小设备号的.首先udev在sys中寻找到大小设备号,必然/sys/class/tty/vcs/dev中有”7:0”便是了.根据这个号再到/etc/rules.d中寻找创建规则进行创建.

 

2.    udev和module之间的关系

2.1  Module Loading

    被编译成模块的设备驱动可能会有一个基于bus-specific identifier的别名,这个别名就指明了其支持的设备.可以通过modinfo看到.比如 snd-fm801驱动支持Vendor ID 0x1319,device ID 0x0801的PCI设备,那么它的别名就是“pci:v00001319d00000801sv*sd*bc04sc01i*”对应大多数设备又可以从sys中找到与这个别名对应的标识. 比如/sys/bus/pci/devices/0000:00:0d.0/modalias中就包含了这样的字符串“pci:v00001319d00000801sv00001319sd00001319bc04sc01i00”,这样就在设备和驱动之建立了联系.

    所以udevd便调用/sbin/midprobe使用上面的这些别名来加载设备的驱动.

 

    好,现在来回答我们的第二个问题: start_udev这个tools是如何在系统启动时候加载设备驱动的?

  

    补充一下:这里指的start_udev和udevstart都是用在fedora下的两个tools, start_udev实质上就是调用udevstart.如果从tarball编译udev是没有这两个的,取而代之的是: 一个udev脚本, 一个udevtrigger(这个作用和udevstart相同).

 

    在fedora系统中,start_udev将会被在rc.sysinit前调用,也就是kernel执行完后第一程式.这个时候内存中的驱动只有包含在内核中的或者通过initrd方式加载的. 依然有许多设备虽然系统已经识别到,但是并没有加载驱动. 在这些系统识别到的设备我们就能在/sys下找到对应的设备目录,目录中有一个uevent的文件,其实也就是系统识别到设备时候发出的event事件.

    由于在start_udev之前,系统中并没有处理uevents的handler,所以设备对应的模块并没有被加载.

    Start_udev开始后首先做的是同1.2 udev bootscript同样的事情.然后其便开始遍历/sys目录,寻找并试图打开uevent文件.(找到并能打开这个文件就代表有这个设备存在),如果寻找到就往里面写入”add”,相当于再次触发event事件. 但是这个时候udevd守护进程已经开启,它捕捉到了这个事件,便通过/sys下的modalias获得驱动对应模块的别名,然后调用modprobe加载.

 

2.2  udev处理热插拔/动态设备  

    当你插入一个设备比如说USB Disk,内核发现设备连接并产生一个uevent,这个uevent被udevd捕获并按照上述的方法处理.

 

3.    不适合上述方法的模块加载情形

    Udev只能加载那些有 bus-specific别名,并且bus驱动将必要的设备别名正确的写在sysfs的modalias里面的设备模块.对于其他情况的情况就要用其他方法了. 这样检查一个模块是否被udev支持也就是通过modinfo看模块的命名并在/sys/bus寻找modalias文件.

  

    那么对于不适合上述条件的module,对于”wrapper”形式的可以通过修改/etc/modprobe.conf 添加“install module_1 /sbin/modprobe module_2”也就是在安装module_1的时候自动安装module_2. 当然不是”wrapper”形式的,就通过修改开机脚本,手动添加了.(” wrapper”意思就是说module_1是作为module_2的补充,本身并没有什么意义)

 

    现在回到第一个问题: udev创建设备文件需要事先有设备驱动,而Linux内核默认在打开设备文件的时候加载驱动?那么这个先有鸡还是先有鸡蛋的问题是如何解决的?

    Udev创建设备名前是需要驱动的,那么那些符合udev自动加载的模块(实质上是udev调用modprobe)在udevstart中便自动加载好了驱动. 当然其他的设备,如果你在udev创建设备前,没有手动的加载的话,那么是自然不能创建设备文件的了.

文章出处：http://www.diybl.com/course/6_system/linux/Linuxjs/200868/123630.html

 

 

 

说来惭愧，基于ARM平台的驱动做了这么长时间了，以前一直在kernel里面忙活，很少了
解上层应用相关的发展，也没有接触过HAL和
DBUS。因为最近做的项目上层是基于X86的软件框架来做，和以前的模式也有较大的变化
，借此机会也想了解一下上层应用和底层驱动的配合和以前有什么不同，所以很自然的就
需要了解Hal。记录一下自己的学习理解吧。
本人的能力和测试时间有限，可能下文中有些理解、分析不一定准确，欢迎联系指正。

1 相关说明

1.1 网站资源
HAL的官方网址：http://www.freedesktop.org/wiki/Software/hal
http://opensolaris.org/os/project/tamarack/hal_re.html solaris系统上的同志写的
一篇分析HAL框架原理的文章。很好，就是版本稍微有点旧
http://people.freedesktop.org/~david/talks/dynamic-device-handling-OLS-2006.pd
f 2006年Linux研讨会上，Hal的作者David Zeuthen所提交的Paper。
顺便提一下，研讨会的网址是：http://www.linuxsymposium.org/ 有不少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.10
2 理解HAL

2.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设备，它支持哪些数据格式啊
之类的信息，对应用层?绦蛞彩怯幸庖宓模侵皇峭ü齋ysfs接口并不能得到，而通过
Linux
V4L2子系统所定义的的一些标准接口函数，通过IOCTL可以得到这些信息。通常这是由HAL
服务进程调用相应的callout去probe得到。类似还有很多子系统都定义了自己标准的接口
函数，这为HAL获取进一步的设备信息提供了可能性。次外，设备的当前状态啊，等信息
，也可能由Addon通过某
些接口得到。

Ø
通过fdi设备信息文件得到。还有些信息，可能是一些通用的设备信息（比如？要举个例
子），或者是通过对硬件本身的探测也无法获得的信息，比如某些键盘上的某些特殊功能
键的定义等等，还有可能是一些权限控制信息等，这些信息可以通过fdi文件添加到HAL的
设备对象信息数据中。

2.4 HAL的相关文件

首先是硬件信息文件fdi的路径会有：
/usr/share/hal/fdi 通常是由系统程序安装包提供的文件。
/etc/hal/fdi 这里是用户或者管理员修改fdi的位置。
这两个路径下各自存在information policy preprobe等3个目录，用来存放不同用途的
fdi文件。后面再解释。

其次是HAL的一些Callout和Addon，他们位于 /usr/lib/hal/scripts 及 /usr/lib/hal/
下面

再有一些与HAL本身相关的配置文件等：
/etc/init.d/hal hal的启动脚本
/etc/udev/rules.d/95-hal.rules HAL在UDEV中的规则
/etc/dbus-1/system.d/hal.conf HAL的一些常用的Interface在DBUS中的权限设置。

相关程序
/usr/bin/lshal
/usr/bin/hal-device
/usr/bin/hal-get-property
/usr/bin/hal-set-property
/usr/bin/hal-find-by-capability
/usr/bin/hal-find-by-property
/usr/bin/hal-disable-polling
/usr/bin/hal-is-caller-locked-out
/usr/bin/hal-lock
/usr/sbin
/usr/sbin/hald

2.5 HAL的设备检测流程
Hal通过udev发现一个新的设备。
首先，处理 fdi/preprobe 目录下所有匹配的文件。这个目录下的文件，典型的用途是通
过设置info.ignore属性，禁止以后的其它操作，这么做的目的通常是为了绕过某些硬件
bug或者忽略某些设备。但也不局限于此，凡是你希望在HAL对设备进行探测操作之前要处
理的事情，都可以放在这里。
而后，HAL调用preprobe中可能指定的callout做一些额外的预处理工作。
HAL开始做实际的硬件探测工作
HAL处理fdi/information目录下的所有相关文件。这里的文件的典型应用是添加一些设备
相关的信息。比如，根据bus和 vendorID 等信息匹配USB接口的某个品牌的MP3，添加其
所支持的音频格式信息（相当于以配置文件的形式，人为的告知系统这个MP3支持什么格
式）
HAL处理fdi/policy目录下的所有相关文件。这里的文件的典型应用是关联设备对象可能对应需要的Addon和Callout，例如键盘设备可能会需要绑定一个名为hald-addon-keyboard的addon，HAL调用Callout ，通常来说Callout都是一些做Probe用途的程序，运行过就退出。
HAL调用Addon，Addon通常是用来监听设备状态的服务进程，生命周期和设备的生命周期
一致。
HAL将设备对象暴露出来完成整个设备检测流程。

2.6 HAL如何监听设备变更情况
做为硬件抽象层，HAL也必须负责对设备的动态变化进行监测，实时更新设备对象的信息
。这需要多方面的信息来源。
首先是UDEV：
在/etc/udev/rules.d/95-hal.rules 中，为HAL添加了下面一条规则，目的是让Udev把设
备变更信息通过socket发送给HAL。
RUN+="socket:/org/freedesktop/hal/udev_event"
在HALD的启动过程中，hald会打开并监听这个socket。

其次是通过某些addon去监听硬件行为
由于不同的硬件，有着很不同的行为，HAL还会通过一些特定的Addon来监听设备的状态变
更情况。例如针对input类设备，hald会启动一个 hald-addon-input 的Addon，它的其中
一个功能就是监听键盘事件，如果其中有sw类的事件（如sw_lid
因该是表示笔记本盖的开合，好像电源管理会模拟这个事件）则会去修改设备对象对应的
状态属性。其它Addon没有仔细研究。
BBTBOY 发表于 2008-8-15 13:18
3 使用HAL

3.1 HAL相关的一些工具
要使用hal，从hal中获得硬件相关的信息，当然可以编程啦，其次，可以使用dbus-send
工具来操作HAL的interface：
例如查询当前平台都有哪些设备：
dbus-send --system --print-reply --dest=org.freedesktop.Hal /org/freedesktop/H
al/Manager org.freedesktop.Hal.Manager.GetAllDevices

当然，通过Dbus接口可以完成很强大的功能，但是多数情况下，我们可能只需要完成一些
简单的操作，那么我们可以使用例如：
3.1.1 Lshal
直接使用Lshal可以列出当前平台上的设备对象及这些设备对象的所有属性。
Lshal –t 可以以树的形式列出所有设备对象及它们的层次关系。
Lshal –m 可以用来检测hal的服务进程所发出的设备变更的信息，例如我插入了一个USB
接口的读卡器，得到下列输出：
17:31:39.068: usb_device_4cf_8819_000100000000 added
17:31:39.202: usb_device_4cf_8819_000100000000_if0 added
17:31:39.225: usb_device_4cf_8819_000100000000_usbraw added
17:31:44.130: usb_device_4cf_8819_000100000000_if0_scsi_host added
17:31:44.136: usb_device_4cf_8819_000100000000_if0_scsi_host_scsi_device_lun0
added
17:31:44.138: usb_device_4cf_8819_000100000000_if0_scsi_host_scsi_device_lun0_
scsi_generic added
17:31:44.228: storage_serial_Myson_SD_MMC_MS_Reader_000100000000_0_0 added

3.1.2 Hal-device
Hal-device也可以用来显示当前设备对象，此外还可以用-a / -r参数来添加,删除设备对
象，例如：

/ # hal-device -a /org/freedesktop/Hal/devices/try // my input
tmp udi: /org/freedesktop/Hal/devices/tmpe0743
platform.id = 'hello' //my input
created: /org/freedesktop/Hal/devices/try

/ # hal-device /org/freedesktop/Hal/devices/try
udi = '/org/freedesktop/Hal/devices/try'
platform.id = 'hello' (string)
info.udi = '/org/freedesktop/Hal/devices/try' (string)

3.1.3 配置文件
当然Hal的最常见的用法，还是通过修改和创建HAL的fdi文件，借助基于HAL的一系列程序
，完成个人所需的定制的功能。
例如，将你的USB接口的MP3在自动插入时，以指定的名字Mount到指定的位置等。

4 其它
4.1 基于HAL的一些library
前面说到，HAL的作者认为HAL真正起更大作用的时候，是当一些library也开始基于hal实
现他们的一些接口的时候。
大概查找了一下，发现的确有一些这样的library，例如 alsa系统中，有一个library实
现了名为halalsasink
的plugin，这个sink接受UDI作为他的audio设备名来处理音频的播放。这样理论说来，上
层应用无需知道，到底使?玫氖悄母鲆羝瞪璞福恍枰此璧腸apability查找到设备对
象，将它的UDI传给halalsasink即可。Alsa本身的硬件配置管理功能就比较强大，这个例
子可能看不出太大的好
处，不过，至少是一个实际的示例吧。