introduction
This article briefly introduces the driver subsystem in OpenHarmony, including: the location of the driver subsystem in the Hongmeng system, where to check the source code and official documents of the driver subsystem, and the core of the driver subsystem - the HDF driver framework.
Since the beginning of this article, the next few articles introducing the driver subsystem rely on the development environment as follows:
(1) Development board: BearPi-HM_Micro_small development board, OpenHarmony 3.0.
(2) Development IDE: DevEco Device Tool (Release) v3.0.0
So I suggest you to read first:
"Building a pure Ubuntu development environment for BearPi-HM_Micro_Small"
"Hello_World of BearPi-HM_Micro_Small"
OpenHarmony's technical architecture https://gitee.com/openharmony#section2502124574318
The driver subsystem is part of the OpenHarmony kernel layer, and its core is a HDF (Hardware Driver Fundation) hardware driver framework .
1. The source code of the driver subsystem
You can check the source code of the driver subsystem in the following two places: the local OpenHarmony project and the OpenHarmony code repository on Code Cloud.
1. The source code corresponding to the driver subsystem is under the drivers directory of the OpenHarmony project.
2. The source code of the driver subsystem mainly includes the following code warehouses on Code Cloud:
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. Official documents
In addition to the source code, official documents should be the most basic and important learning materials for learning Hongmeng OS. The following are official documents related to the driver subsystem (it is recommended to focus on reading parts 2 and 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开发板。
3. HDF driver framework
3.1 What is HDF?
Driving development is like building a house. The construction company first builds the frame and infrastructure of the house, and then each household completes the decoration of the house according to their own needs on this basis. Driver developers are based on the HDF driver framework provided by OpenHarmony, according to the requirements of the framework, using some basic functions (capabilities) provided by the framework to develop drivers for various devices.
3.2 What capabilities can HDF provide?
The capabilities provided by HDF (Hardware Driver Framework) mainly include the following three aspects:
1. Load the driver.
HDF is responsible for loading drivers and supports two driver loading methods: on-demand loading and sequential loading.
On-demand loading is divided into three situations: (a) the driver is loaded by default during the system startup process; (b) when the system supports fast startup, the driver is loaded after the system startup is completed, otherwise it is the same as (a) ; (c) The driver is not loaded by default. Only when the application needs to use the driver and finds that the driver does not exist, HDF will try to dynamically load the driver.
Sequential loading: Each driver has a priority. When multiple drivers are to be loaded, the one with the higher priority is loaded first, and then the one with the lower priority is loaded.
2. Centralized management of the services provided by the driver.
The services provided by the driver are centrally managed by HDF, and the application can directly obtain the related services of the driver through the capability interface provided by the HDF framework.
3. Provide a unified driving message mechanism.
The driver program in the kernel mode and the application program in the user mode can exchange messages through HDF.
3.3 Device driver model defined by HDF
To develop a driver, you must first understand the device driver model defined by HDF , as shown in the figure below. HDF defines a componentized device driver model, which can provide developers with more refined device driver management and make the development and deployment of device drivers more standardized.
The device driver model defined by HDF includes: Host (device collection) , Device (device) , Device Node (device node) , Driver (driver) , of which the first two belong to logical concepts, and the latter two belong to physical concepts.
(1) According to the requirements of HDF, generally put multiple devices of the same type, similar functions or closely related business into one Host (device collection) . Host itself has two properties, as shown in the following table:
| Attributes | value | describe |
|---|---|---|
| hostName | string | The name of the device collection. |
| priority | Integer, 0~200 | The priority of the device collection. The higher the value, the lower the priority; if the priority is the same, the loading order is not guaranteed. |
(2) Device (device) itself has no attributes, and each device (device) can have one or more Device Nodes (device nodes) .
(3) Each Device Node (device node) has a corresponding (many-to-one, one-to-one) Driver (driver) . The attributes defined by the HDF driver framework for device nodes are shown in the following table:
| Attributes | value | describe |
|---|---|---|
| moduleName | string | The driver corresponding to each device node is called a module, and each module has a moduleName. |
| preload | integer | The way the driver is loaded by HDF. 0: On-demand loading mode (a), 1: On-demand loading mode (b), 2: On-demand loading mode©. |
| priority | Integer, 0~200 | Driver priority. The higher the value, the lower the priority; if the priority is the same, the loading order is not guaranteed. |
| serviceName | string | The name of the service published by the driver must be unique. |
| policy | integer | Drive the strategy for publishing services externally. |
| permission | integer | The read and write permissions of device nodes generally use octal integers prefixed with 0, which is similar to the concept of file permissions in linux. |
| deviceMatchAttr | string | Custom properties for matching device nodes. |
Enumeration type: the loading method of the driver
typedef enum {
DEVICE_PRELOAD_ENABLE = 0,
DEVICE_PRELOAD_ENABLE_STEP2,
DEVICE_PRELOAD_DISABLE,
DEVICE_PRELOAD_INVALID
} DevicePreload;
Enumeration type: strategy for driving external publishing services
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 APIs of HDF
The API provided by the HDF driver framework is described in detail in the official document (the second part of this article). I also collected the APIs I have used in another article "API of the HDF driver framework".