没有合适的资源?快使用搜索试试~ 我知道了~
hal学习.docx
1.该资源内容由用户上传,如若侵权请联系客服进行举报
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
版权申诉
0 下载量 177 浏览量
2023-04-05
20:10:04
上传
评论
收藏 1.05MB DOCX 举报
温馨提示
试读
32页
。
资源推荐
资源详情
资源评论
一,介绍:
硬件抽象层(Hardware Abstraction Layer,HAL)是一个守护进程,它允许桌面应用程序
即时读取硬件信息,这样,无论接口或设备类型如何,应用程序都能找到并使用它们。用这
种方法,图形界面以一种无缝、一致的模式为用户提供所有的资源。
二,热插拔:
热插拔会发生很多事情,HAL 只是其中一部分。当一个新设备被加入,例如插入一个U
盘,会发生以下事情(粗略的):
Udev 创建一个设备节点(如/dev/sdb1),然后加载必需的驱动/模块。
HAL 守护进程接到 D-Bus 的通知,将设备及其相关信息加入到数据库。
HAL 通过 D-Bus 将新设备的加入这件事广播给所有订阅程序,如Thunar 对此将在
快捷边栏上显示图标,或者 Metacity/Nautilus 对此会在桌面添加一个图标。
可能还有其它监听程序,如卷管理器或者 AutoFS,它被配置为自动创建挂载点并
挂载某些类型的驱动器, 当 iPod 插入时启动 Rhythmbox ,等等。
三,hal 主要功能:
获取/更改设备的属性值。
设备插入/拔除时,通知相关应用程序。
设备属性或能力变化时,通知相关应用程序。
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 的分层视图如下:
udev 通过 NetLink 注册内核的设备事件,当有设备插入/拔除时,udev 就会收到通知,它会
从事件中所带参数和 sysfs 中的信息,加载适当的驱动程序,创建 dev 下的结点,让设备处
于可用的状态。
udev 只是一个框架,它的行为完全受它的规则所控制,这些规则存放在目录/etc/udev/rules.d/
中,其中 90-hal.rules 是用来让 udev 把设备插入/拔除的事件通过 socket
socket:/org/freedesktop/hal/udev_event 转发给 HAL 的。
HAL 挂在 socket:/org/freedesktop/hal/udev_event 上等待事件,有事件发生时就调用函数
hald_udev_data 处理,它先从事件中取出主要参数,创建一个hotplug_event 对象,把它放入
事件队列中,然后调用 hotplug_event_process_queue 处理事件。
函数 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_genera
te_add_hotplug_event)。
6.
函数 hotplug_event_begin_sysfs 中,如果是插入设备,则创建一个设备对象,设置设备的属
性,调用相关 callouts,然后放入设备列表中,并触发 signal 让 dbus 通知相关应用程序。如
果是拔除设备,则调用相关 callouts,然后从设备列表中删除,并触发 signal 让 dbus 通知相
关应用程序。
应用程序可以主动调用 HAL 提供的 DBUS 接口函数,这些函数在 libhal.h 中有定义。应用
程序也可以注册 HAL 的 signal,当设备变化时,HAL 通过 DBUS 上报事件给应用程序。
callout 是 HAL 一种扩展方式,它在设备插入/拔除时执行。可以在设备信息文件中
(/usr/share/hal 目录)指定。
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 检测一些特殊按键,并触发相应事件。
简单的说,HAL 就是一个设备数据库,它管理当前系统中所有的设备,你可以以多种灵活的方
式去查询这些设备,可以获取指定设备的特性,可以注册设备变化事件。
Rockie Cheng 根据 Jollen 的 HAL 讲座与代码整理(http://www.jollen.org/blog/)
http://hi.baidu.com/aokikyon
aokikyon@gmail.com
Android 的 HAL(Hardware Abstract Layer 硬件抽象层)是 Google 因应厂商「希望不公
开源码」的要求下,所推出的新观念,其架构如下图。虽然HAL 现在的「抽象程度」还不
足,现阶段实作还不是全面符合 HAL 的架构规划,不过也确实给了我们很好的思考空间。
这是 Patrick Brady (Google) 在 2008 Google I/O 所发表的演讲「Anatomy & Physiology of
an Android」中,所提出的 Android HAL 架构图。从这张架构图我们知道,HAL 的目的是
为了把 Android framework 与 Linux kernel 完整「隔开」。让 Android 不至过度依赖
Linux kernel,有点像是「kernel independent」的意思,让 Android framework 的开发能
在不考虑驱动程序的前提下进行发展。
在 HAL 的架构实作成熟前(即图 1 的规划),我们先就目前 HAL 现况做一个简单的分析。
另外,目前 Android 的 HAL 实作,仍旧散布在不同的地方,例如 Camera、WiFi 等,因
此上述的目录并不包含所有的 HAL 程序代码。
2 HAL 的过去
图 2:Android HAL / libhardware_legacy
过去的 libhardware_legacy 作法,比较是传统的「module」方式,也就是将 *.so 档案当
做「shared library」来使用,在 runtime(JNI 部份)以 direct function call 使用 HAL module。
透过直接函数呼叫的方式,来操作驱动程序。当然,应用程序也可以不需要透过 JNI 的方
式进行,直接以加载 *.so 檔(dlopen)的做法呼叫*.so 里的符号(symbol)也是一种方
式。总而言之是没有经过封装,上层可以直接操作硬件。
图 3:Android HAL / libhardware
现在的 libhardware 作法,就有「stub」的味道了。HAL stub 是一种代理人(proxy)的
概念,stub 虽然仍是以 *.so 檔的形式存在,但 HAL 已经将 *.so 档隐藏起来了。Stub 向
剩余31页未读,继续阅读
资源评论
apple_51426592
- 粉丝: 9580
- 资源: 9658
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功