概述
HDF（Hardware Driver Foundation）驱动框架，为驱动开发者提供驱动框架能力，包括驱动加载、驱动服务管理、驱动消息机制和配置管理。并以组件化驱动模型作为核心设计思路，让驱动开发和部署更加规范，旨在构建统一的驱动架构平台，为驱动开发者提供更精准、更高效的驱动管理的开发环境，力求做到一次开发，多系统部署。
- 驱动加载
HDF驱动框架提供把和配置的设备列表匹配成功的驱动程序加载起来的功能
- 驱动服务管理
HDF框架可以集中管理驱动服务，开发者可直接通过HDF框架对外提供的能力接口获取驱动相关的服务
- 驱动消息机制
HDF框架提供统一的驱动消息机制，支持用户态应用向内核态驱动发送消息，也支持内核态驱动向用户态应用发送消息
- 配置管理
HCS是HDF驱动框架的配置描述源码，内容以Key-Value为主要形式。它实现了配置代码与驱动代码解耦，便于开发者进行配置管理
framework代码目录：
框架交互流程：
驱动模型
HDF框架将一类设备驱动放在同一个Host（设备容器）里面，用于管理一组设备的启动加载等过程。在划分Host时，驱动程序是部署在一个Host还是部署在不同的Host，主要考虑驱动程序之间是否存在耦合性，如果两个驱动程序之间存在依赖，可以考虑将这部分驱动程序部署在一个Host里面，否则部署到独立的Host中是更好的选择。
Device对应一个真实的物理设备。DeviceNode是设备的一个部件，Device至少有一个DeviceNode。每个DeviceNode可以发布一个设备服务。驱动即驱动程序，每个DevicdNode唯一对应一个驱动，实现和硬件的功能交互。
HDF驱动模型如下图所示：
驱动加载
HDF驱动框架提供把和配置的设备列表匹配成功的驱动程序加载起来的功能，支持按需加载和按序加载两种策略，具体设备的加载策略由配置文件中的preload字段来控制，配置值参考如下：
按需加载
- preload字段配置为0（DEVICE_PRELOAD_ENABLE），则系统启动过程中默认加载。
- preload字段配置为1（DEVICE_PRELOAD_ENABLE_STEP2），当系统支持快速启动的时候，则在系统完成之后再加载这一类驱动，否则和DEVICE_PRELOAD_ENABLE含义相同。
- preload字段配置为2（DEVICE_PRELOAD_DISABLE），则系统启动过程中默认不加载，支持后续动态加载，当用户态获取驱动服务消息机制时，如果驱动服务不存在，HDF框架会尝试动态加载该驱动。
按序加载（默认加载策略）
配置文件中的priority（取值范围为整数0到200）是用来表示host（驱动容器）和驱动的优先级的。不同的host内的驱动，host的priority值越小，驱动加载优先级越高；同一个host内驱动的priority值越小，加载优先级越高。
异常恢复（用户态驱动）
当驱动服务异常退出时，恢复策略如下：
- preload字段配置为0（DEVICE_PRELOAD_ENABLE）或1（DEVICE_PRELOAD_ENABLE_STEP2）的驱动服务，由启动模块拉起host并重新加载服务。
- preload字段配置为2（DEVICE_PRELOAD_DISABLE）的驱动服务，需业务模块注册HDF的服务状态监听器，当收到服务退出消息时，业务模块调用LoadDevice重新加载服务。
驱动服务管理
驱动服务是HDF驱动设备对外提供能力的对象，由HDF框架统一管理。驱动服务管理主要包含驱动服务的发布和获取。HDF框架定义了驱动对外发布服务的策略，由配置文件中的policy字段来控制，policy字段的取值范围以及含义如下：
当驱动需要以接口的形式对外提供能力时，可以使用HDF框架的驱动服务管理能力。
驱动消息机制管理
当用户态应用和内核态驱动需要交互时，可以使用HDF框架的消息机制来实现。
消息机制的功能主要有以下两种：
- 用户态应用发送消息到驱动。
- 用户态应用接收驱动主动上报事件。
配置管理
HCS（HDF Configuration Source）是HDF驱动框架的配置描述源码，内容以Key-Value为主要形式。它实现了配置代码与驱动代码解耦，便于开发者进行配置管理。HC-GEN（HDF Configuration Generator）是HCS配置转换工具，可以将HDF配置文件转换为软件可读取的文件格式：
- 在弱性能环境中，转换为配置树源码或配置树宏定义，驱动可直接调用C代码或宏式APIs获取配置。
- 在高性能环境中，转换为HCB（HDF Configuration Binary）二进制文件，驱动可使用HDF框架提供的配置解析接口获取配置。
以下是使用HCB模式的典型应用场景：
图2 配置使用流程图
HCS经过HC-GEN编译生成HCB文件，HDF驱动框架中的HCS Parser模块会从HCB文件中重建配置树，HDF驱动模块使用HCS Parser提供的配置读取接口获取配置内容。
配置语法
具体细节在此省略，后面会有些例子。
配置生成
hc-gen 是配置生成的工具，可以对HCS配置语法进行检查并把HCS源文件转化成HCB二进制文件，类似于设备树工具dtc
主要常用用法：
- 生成.c/.h配置文件方法：
- 生成HCB配置文件方法：
- 生成宏定义配置文件方法：
- 反编译HCB文件为HCS方法：
平台驱动举例
适配最主要的工作就是根据具体硬件实现适配层相关的钩子函数，并配置好相应的属性文件，即hcs，大致分为以下步骤：
实例化驱动入口
配置属性文件
实例化UART控制器对象
驱动调试
统一服务模式
在统一模式下，所有的控制器都被核心层统一管理，并由核心层统一发布一个服务供接口层
比如I2C模块：
- device_info.hcs配置参考
- i2c_config.hcs配置参考
独立服务模式
独立服务模式下，核心层不会统一发布一个服务供上层使用，因此这种模式下驱动要为每个控制器发布一个服务，具体表现为：
- 驱动适配者需要实现HdfDriverEntry的Bind钩子函数以绑定服务。
- device_info.hcs文件中deviceNode的policy字段为1或2，不能为0。
比如UART模块：
- device_info.hcs 配置参考：
- uart_config.hcs 配置参考：
统一服务模式相较独立模式，可以节省资源，方便管理
外设驱动举例
这里列举一个稍微简单点的Light驱动模型，Light驱动模型为上层Light硬件服务层提供稳定的灯控制能力接口，包括获取灯类型、配置点灯模式、配置灯闪烁效果、点灯、熄灯等。
Light驱动模型流程：
以标准系统RK3568为例，介绍Light模块驱动加载及运行流程：
1：Device Manager从device_info.hcs配置文件中读取Light设备管理配置信息。
2：Device Manager从light_config.hcs配置文件中读取Light数据配置信息。
3：HCS Parser解析Light设备管理配置信息，加载对应的Light Host，并控制Host完成驱动的加载。
4：Light Proxy获取到Light HDI接口服务实例后，通过IPC（Inter-Process Communication）调用到Light Stub。
5：Light Stub主要处理与IPC相关的业务逻辑，完成参数反序列化后调用Light Controller。
6：Light Controller中是HDI接口的真正实现，通过IPC调用Light抽象驱动接口，进一步操作Light硬件设备。
思考总结
- HDF最核心几大块：配置管理，驱动管理，对外服务，消息机制
- 对外接口侧重于服务，消息，而不是设备节点，这个是很大的一个转变
以上内容主要概括了《OpenHarmony之HDF驱动框架》基础知识，为了让大家更快的了解《OpenHarmony4.0&Next》，我特意邀请几位行业大佬，联合整理了一份思维导图提供大家参考学习，大家可以根据自己的情况借鉴：《做鸿蒙应用开发到底学习些啥？》
除了上面整理的思维导图以外，这里还特别整理的一份《鸿蒙 (Harmony OS)开发学习手册》给大家进行参考学习：
一、入门必看
1. 应用开发导读(ArkTS)
2. ……
二、HarmonyOS 概念《鸿蒙开发学习指南》
1. 系统定义
2. 技术架构
3. 技术特性
4. 系统安全
5........
三、如何快速入门？《
1. 基本概念
2. 构建第一个ArkTS应用
3. 构建第一个JS应用
4. ……
四、开发基础知识
1. 应用基础知识
2. 配置文件
3. 应用数据管理
4. 应用安全管理
5. 应用隐私保护
6. 三方应用调用管控机制
7. 资源分类与访问
8. 学习ArkTS语言
9. ……
五、基于ArkTS 开发
1. Ability开发
2. UI开发
3. 公共事件与通知
4. 窗口管理
5. 媒体
6. 安全
7. 网络与链接
8. 电话服务
9. 数据管理
10. 后台任务(Background Task)管理
11. 设备管理
12. 设备使用信息统计
13. DFX
14. 国际化开发
15. 折叠屏系列
16. ……
更多了解更多鸿蒙开发的相关知识可以参考：《鸿蒙基础入门开发宝典！》
