未验证 提交 f5c75d3c 编写于 作者: L liyan 提交者: Gitee

update zh-cn/device-dev/driver/driver-hdf-manage.md.

Signed-off-by: Nli-yan339 <liyan339@h-partners.com>
Signed-off-by: Nliyan <liyan339@h-partners.com>
上级 91bf9827
......@@ -4,23 +4,23 @@
HDF(Hardware Driver Foundation)驱动框架,为驱动开发者提供驱动框架能力,包括驱动加载、驱动服务管理、驱动消息机制和配置管理。并以组件化驱动模型作为核心设计思路,让驱动开发和部署更加规范,旨在构建统一的驱动架构平台,为驱动开发者提供更精准、更高效的驱动管理的开发环境,力求做到一次开发,多系统部署。
##### 驱动加载
### 驱动加载
HDF驱动框架提供把和配置的设备列表匹配成功的驱动程序加载起来的功能。
##### 驱动服务管理
### 驱动服务管理
HDF框架可以集中管理驱动服务,开发者可直接通过HDF框架对外提供的能力接口获取驱动相关的服务。
##### 驱动消息机制
### 驱动消息机制
HDF框架提供统一的驱动消息机制,支持用户态应用向内核态驱动发送消息,也支持内核态驱动向用户态应用发送消息。
##### 配置管理
### 配置管理
HCS(HDF Configuration Source)是HDF驱动框架的配置描述源码,内容以Key-Value为主要形式。它实现了配置代码与驱动代码解耦,便于开发者进行配置管理。
##### 驱动模型
### 驱动模型
HDF框架将一类设备驱动放在同一个Host(设备容器)里面,用于管理一组设备的启动加载等过程。在划分Host时,驱动程序是部署在一个Host还是部署在不同的Host,主要考虑驱动程序之间是否存在耦合性,如果两个驱动程序之间存在依赖,可以考虑将这部分驱动程序部署在一个Host里面,否则部署到独立的Host中是更好的选择。Device对应一个真实的物理设备。DeviceNode是设备的一个部件,Device至少有一个DeviceNode。每个DeviceNode可以发布一个设备服务。驱动即驱动程序,每个DevicdNode唯一对应一个驱动,实现和硬件的功能交互。HDF驱动模型如下图所示:
......@@ -32,8 +32,6 @@ HDF框架将一类设备驱动放在同一个Host(设备容器)里面,用
### 驱动加载
#### 驱动加载策略
HDF驱动框架提供把和配置的设备列表匹配成功的驱动程序加载起来的功能,支持按需加载和按序加载两种策略,具体设备的加载策略由配置文件[驱动开发](#驱动配置)中的preload字段来控制,配置值参考如下:
```c
......@@ -45,25 +43,25 @@ typedef enum {
} DevicePreload;
```
**按需加载**
#### 按需加载
preload字段配置为0(DEVICE_PRELOAD_ENABLE),则系统启动过程中默认加载。
- preload字段配置为0(DEVICE_PRELOAD_ENABLE),则系统启动过程中默认加载。
​ preload字段配置为1(DEVICE_PRELOAD_ENABLE_STEP2),当系统支持快速启动的时候,则在系统完成之 后再加载这一类驱动,否则和DEVICE_PRELOAD_ENABLE含义相同。
- preload字段配置为1(DEVICE_PRELOAD_ENABLE_STEP2),当系统支持快速启动的时候,则在系统完成之后再加载这一类驱动,否则和DEVICE_PRELOAD_ENABLE含义相同。
preload字段配置为2(DEVICE_PRELOAD_DISABLE),则系统启动过程中默认不加载,支持后续动态加载, 当用户态获取驱动服务[消息机制](#驱动消息机制管理)时,如果驱动服务不存在,HDF框架会尝试动态加载该驱动。
- preload字段配置为2(DEVICE_PRELOAD_DISABLE),则系统启动过程中默认不加载,支持后续动态加载,当用户态获取驱动服务[消息机制](#驱动消息机制管理)时,如果驱动服务不存在,HDF框架会尝试动态加载该驱动。
**按序加载(默认加载策略)**
#### 按序加载(默认加载策略)
配置文件中的priority(取值范围为整数0到200)是用来表示host(驱动容器)和驱动的优先级。不同的host内的 驱动,host的priority值越小,驱动加载优先级越高;同一个host内驱动的priority值越小,加载优先级越高。
配置文件中的priority(取值范围为整数0到200)是用来表示host(驱动容器)和驱动的优先级的。不同的host内的驱动,host的priority值越小,驱动加载优先级越高;同一个host内驱动的priority值越小,加载优先级越高。
**异常恢复(用户态驱动)**
#### 异常恢复(用户态驱动)
当驱动服务异常退出时,恢复策略如下:
preload字段配置为0(DEVICE_PRELOAD_ENABLE)或1(DEVICE_PRELOAD_ENABLE_STEP2)的驱动服 务,由启动模块拉起host并重新加载服务。
- preload字段配置为0(DEVICE_PRELOAD_ENABLE)或1(DEVICE_PRELOAD_ENABLE_STEP2)的驱动服务,由启动模块拉起host并重新加载服务。
preload字段配置为2(DEVICE_PRELOAD_DISABLE)的驱动服务,需业务模块注册HDF的服务状态监听器, 当收到服务退出消息时,业务模块调用LoadDevice重新加载服务。
- preload字段配置为2(DEVICE_PRELOAD_DISABLE)的驱动服务,需业务模块注册HDF的服务状态监听器,当收到服务退出消息时,业务模块调用LoadDevice重新加载服务。
### 驱动服务管理
......@@ -107,15 +105,15 @@ typedef enum {
#### 使用场景
当用户态应用和内核态驱动需要交互时,可以使用HDF框架的消息机制来实现。
当用户态应用和内核态驱动需要交互时,可以使用HDF框架的消息机制来实现。
#### 接口说明
消息机制的功能主要有以下两种:
消息机制的功能主要有以下两种:
1. 用户态应用发送消息到驱动。
- 用户态应用发送消息到驱动。
​ 2. 用户态应用接收驱动主动上报事件。
- 用户态应用接收驱动主动上报事件。
**表2** 消息机制接口
......@@ -163,8 +161,6 @@ HCS配置语法保留了以下关键字。
| template | 定义模板节点 | - |
| match_attr | 用于标记节点的匹配查找属性 | 解析配置时可以使用该属性的值查找到对应节点 |
##### 基本结构
HCS主要分为属性(Attribute)和节点(Node)两种结构。
......@@ -268,7 +264,7 @@ bool类型中**true**表示真,**false**表示假。
##### 引用修改
引用修改可以实现修改另外任意一个节点的内容,语法为:
引用修改的作用是在当前节点中修改另外任意一个节点的内容,语法为:
```
node :& source_node
......@@ -355,9 +351,9 @@ root {
}
```
在上述示例中,编译后bar节点即包含attr_0属性也包含attr_1属性,在bar中对attr_0的修改不会影响到foo。
在上述示例中,编译后bar节点既包含attr_0属性又包含attr_1属性,在bar中对attr_0的修改不会影响到foo。
在foo和bar在同级node中可不指定foo的路径,否则需要使用绝对路径引用[引用修改](#引用修改)
当foo和bar在同级node中时可不指定foo的路径,否则需要使用绝对路径引用,绝对路径的介绍请参考[引用修改](#引用修改)
##### 删除
......@@ -712,7 +708,7 @@ HDF使用HCS作为配置描述源码,HCS详细介绍[配置管理](#配置概
- 驱动私有配置信息(可选)
如果驱动有私有配置,则可以添加一个驱动的配置文件,用来填写一些驱动的默认配置信息。HDF框架在加载驱动的时候,会将对应的配置信息获取并保存在HdfDeviceObject中的property里面,通过Bind和Init(参考步骤1)传递给驱动。驱动的配置信息示例如下:
如果驱动有私有配置,则可以添加一个驱动的配置文件,用来填写一些驱动的默认配置信息。HDF框架在加载驱动的时候,会将对应的配置信息获取并保存在HdfDeviceObject中的property里面,通过Bind和Init(参考[驱动实现](#驱动实现))传递给驱动。驱动的配置信息示例如下:
```
root {
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册