OpenHarmony驱动子系统概述
引言
本文简要介绍了OpenHarmony中的驱动子系统，包括：驱动子系统在鸿蒙系统中的位置、到那里去查阅驱动子系统的源码和官方文档，以及驱动子系统的核心——HDF驱动框架。
自本文开始，接下来几篇介绍驱动子系统的文章所依赖的开发环境如下：
（1）开发板：小熊派BearPi-HM_Micro_small开发板，OpenHarmony 3.0。
（2）开发IDE：DevEco Device Tool (Release) v3.0.0
所以建议大家先阅读：
《搭建小熊派BearPi-HM_Micro_Small的纯Ubuntu开发环境》
《小熊派BearPi-HM_Micro_Small之Hello_World》
OpenHarmony的技术架构 https://gitee.com/openharmony#section2502124574318
驱动子系统属于OpenHarmony内核层中的一部分，其 核心 就是一个 HDF（Hardware Driver Fundation）硬件驱动框架 。
一、驱动子系统的源码
可以在以下两个地方查阅驱动子系统的源码：本地的OpenHarmony工程、码云上的OpenHarmony代码仓库。
1、驱动子系统对应的源码在OpenHarmony工程的drivers目录下面。
2、驱动子系统的源码在码云上主要有以下这几个代码仓库：
https://gitee.com/openharmony/drivers_framework
https://gitee.com/openharmony/drivers_hdf_core
https://gitee.com/openharmony/drivers_adapter
https://gitee.com/openharmony/drivers_liteos
https://gitee.com/openharmony/drivers_peripheral
https://gitee.com/openharmony/drivers_interface
https://gitee.com/openharmony/drivers_adapter_khdf_linux
二、官方文档
除了源代码之外，官方文档应该是学习鸿蒙操作系统最基本、最重要的学习资料。以下是与驱动子系统相关官方文档（建议重点阅读第2、3部分）：
1、驱动子系统简介
https://gitee.com/openharmony/docs/blob/OpenHarmony-3.1-Release/zh-cn/readme/%E9%A9%B1%E5%8A%A8%E5%AD%90%E7%B3%BB%E7%BB%9F.md
2、OpenHarmony-v3.1-LTS驱动使用指南
https://docs.openharmony.cn/pages/v3.1/zh-cn/device-dev/driver/driver-hdf-overview.md/
https://gitee.com/openharmony/docs/tree/OpenHarmony-3.1-Release/zh-cn/device-dev/driver
https://gitee.com/openharmony/docs/blob/OpenHarmony-v3.1-Release/zh-cn/device-dev/driver/Readme-CN.md
3、HDF的API
https://device.harmonyos.com/cn/docs/documentation/apiref/core-0000001054718073
4、HUAWEI DevEco Device Tool中的HDF工具使用说明
https://device.harmonyos.com/cn/docs/documentation/guide/hdf-management-0000001077809126
注：HDF功能当前只支持Hi3516DV300开发板。
三、HDF驱动框架
3.1 什么是HDF？
驱动开发就好比是盖房子，建筑公司先把房子的框架和基础设施建好，然后各家各户在这个基础之上按照自己的需求完成房子的装修。驱动程序的开发者就是在OpenHarmony提供的HDF驱动框架的基础之上，按照框架的要求，利用框架提供的一些基本功能（能力），开发各种设备的驱动程序。
3.2 HDF能够提供哪些能力？
HDF（硬件驱动框架）能够提供的能力主要包括以下三个方面：
1、加载驱动。
HDF负责加载驱动，支持两种驱动加载方式：按需加载、按序加载。
按需加载又分成三种情况：（a）在系统启动过程中默认加载驱动程序；（b）当系统支持快速启动时，就等到系统启动完成之后再加载驱动程序，否则与（a）情况相同；（c）默认不加载驱动程序，只有当应用程序需要用到驱动程序且发现驱动程序不存在时，HDF才会尝试动态加载驱动程序。
按序加载：每个驱动都有一个优先级，当要加载多个驱动的时候，先加载优先级高的，再加载优先级低的。
2、对驱动提供的服务进行集中管理。
驱动程序对外提供的服务都由HDF集中管理，应用程序可直接通过HDF框架对外提供的能力接口获取驱动的相关服务。
3、提供统一的驱动消息机制。
内核态的驱动程序与用户态的应用程序之间可通过HDF互发消息。
3.3 HDF定义的设备驱动模型
要开发驱动程序，首先要了解HDF定义的 设备驱动模型 ，如下图所示。HDF定义了一种组件化的设备驱动模型，可以为开发者提供更精细化的 设备驱动管理 ，让 设备驱动的开发和部署 更加规范。
HDF定义的设备驱动模型中，包括：Host（设备集合）、Device（设备）、Device Node（设备节点）、Driver（驱动程序），其中前面两个属于逻辑概念，后面两个属于物理概念。
（1）按照HDF的要求，一般将类型相同、功能相似或业务关联紧密的多种设备放到一个 Host（设备集合） 里面。Host 本身有两种属性，如下表所示：
| 属性 | 取值 | 描述 |
|---|---|---|
| hostName | 字符串 | 设备集合的名称。 |
| priority | 整数，0~200 | 设备集合的优先级。数值越大，优先级越低；如果优先级相同，则不能保证加载顺序。 |
（2）Device（设备） 本身没有属性，每一种 Device（设备） 下面可以有一个或多个 Device Node（设备节点） 。
（3）每一个Device Node（设备节点）都有对应（多对一、一对一）的Driver（驱动程序）。HDF驱动框架给设备节点定义的属性如下表所示：
| 属性 | 取值 | 描述 |
|---|---|---|
| moduleName | 字符串 | 每个设备节点所对应的驱动程序被称为一个module，每一个module都有一个moduleName。 |
| preload | 整数 | 驱动被HDF加载的方式。0：按需加载模式(a)，1：按需加载模式(b)，2：按需加载模式©。 |
| priority | 整数，0~200 | 驱动的优先级。数值越大，优先级越低；如果优先级相同，则不能保证加载顺序。 |
| serviceName | 字符串 | 驱动对外发布的服务的名称，必须唯一。 |
| policy | 整数 | 驱动对外发布服务的策略。 |
| permission | 整数 | 设备节点的读写权限，一般采用以0为前缀的8进制整数，类似于linux的文件权限的概念。 |
| deviceMatchAttr | 字符串 | 用于匹配设备节点的自定义属性。 |
枚举类型：驱动的加载方式
typedef enum {
DEVICE_PRELOAD_ENABLE = 0,
DEVICE_PRELOAD_ENABLE_STEP2,
DEVICE_PRELOAD_DISABLE,
DEVICE_PRELOAD_INVALID
} DevicePreload;
枚举类型：驱动对外发布服务的策略
typedef enum {
SERVICE_POLICY_NONE = 0, //驱动不提供服务
SERVICE_POLICY_PUBLIC = 1, //驱动对内核态发布服务
SERVICE_POLICY_CAPACITY = 2, //驱动对内核态和用户态都发布服务
SERVICE_POLICY_FRIENDLY = 3, //驱动服务不对外发布服务，但可以被订阅
SERVICE_POLICY_PRIVATE = 4, //驱动私有服务不对外发布服务，也不能被订阅
SERVICE_POLICY_INVALID //错误的服务策略
} ServicePolicy;
3.4 HDF的API
HDF驱动框架对外提供的API在官方文档（本文第二部分）中有详细的说明，我在另一篇文章《HDF驱动框架的API》中，也汇集了我已经使用过的API。