1# Driver Development<a name="EN-US_TOPIC_0000001051930361"></a> 2 3- [Introduction](#section157425168112) 4- [How to Develop](#section1969312275533) 5 6## Introduction<a name="section157425168112"></a> 7 8The HDF is designed based on the component-based driver model. It provides more refined driver management to make driver development and deployment more standard. Device drivers of the same type are placed in the same host. You can develop and deploy the drivers separately. One driver can have multiple nodes. [Figure 1](#fig5487113011526) shows the HDF driver model. 9 10**Figure 1** HDF driver model<a name="fig5487113011526"></a> 11 12 13 14 15## How to Develop<a name="section1969312275533"></a> 16 17Driver development based on the HDF consists of two parts: driver implementation and driver configuration. The details are as follows: 18 191. <a name="li35182436435"></a>Implement driver. 20 21 To implement a driver, compile driver service code and register a driver entry. 22 23 - Driver service code 24 25 ``` 26 #include "hdf_device_desc.h" // Header file that describes the APIs provided by the HDF to the driver. 27 #include "hdf_log.h" // Header file that describes the log APIs provided by the HDF. 28 29 #define HDF_LOG_TAG "sample_driver" // Tag contained in logs. If no tag is not specified, the default HDF_TAG is used. 30 31 // The driver service interface must be bound to the HDF for you to use the service capability. 32 int32_t HdfSampleDriverBind(struct HdfDeviceObject *deviceObject) 33 { 34 HDF_LOGD("Sample driver bind success"); 35 return 0; 36 } 37 38 // Initialize the driver service. 39 int32_t HdfSampleDriverInit(struct HdfDeviceObject *deviceObject) 40 { 41 HDF_LOGD("Sample driver Init success"); 42 return 0; 43 } 44 45 // Release the driver resources. 46 void HdfSampleDriverRelease(struct HdfDeviceObject *deviceObject) 47 { 48 HDF_LOGD("Sample driver release success"); 49 return; 50 } 51 ``` 52 53 - Registering the driver entry with the HDF 54 55 ``` 56 // Define the object of the driver entry. The object must be a global variable of the HdfDriverEntry type (defined in hdf_device_desc.h). 57 struct HdfDriverEntry g_sampleDriverEntry = { 58 .moduleVersion = 1, 59 .moduleName = "sample_driver", 60 .Bind = HdfSampleDriverBind, 61 .Init = HdfSampleDriverInit, 62 .Release = HdfSampleDriverRelease, 63 }; 64 65 // Call HDF_INIT to register the driver entry with the HDF framework. When loading the driver, call the Bind function and then the Init function. If the Init function fails to be called, the HDF will call Release to release the driver resource and exit. 66 HDF_INIT(g_sampleDriverEntry); 67 ``` 68 692. Compile the driver code. 70 - Use the **Makefile** template provided by the HDF to compile the driver code. 71 72 ``` 73 include $(LITEOSTOPDIR)/../../drivers/adapter/lite/khdf/lite.mk # (Mandatory) Import the predefined content of the HDF. 74 MODULE_NAME := # Generated result file 75 LOCAL_INCLUDE: = # Header file directory of the driver 76 LOCAL_SRCS : = # Source code file of the driver 77 LOCAL_CFLAGS : = # Custom compilation options 78 include $(HDF_DRIVER) # Import the template Makefile to complete compilation. 79 ``` 80 81 - Link the compilation result file to the kernel image by adding the result file to **hdf\_vendor.mk** in the **vendor** directory. The following is an example: 82 83 ``` 84 LITEOS_BASELIB += -lxxx # Static library generated through linking 85 LIB_SUBDIRS += # Directory of Makefile 86 ``` 87 883. Configure the driver. 89 90 HDF Configuration Source \(HCS\) is the source code that describes the configuration of the HDF. For details about the HCS, see [Driver Configuration Management](driver-hdf-manage.md). 91 92 The driver configuration consists of the driver device description defined by the HDF and private driver configuration information. 93 94 - \(Mandatory\) Driver device description 95 96 The information required for the HDF to load drivers comes from the driver device description defined by the HDF. Therefore, the device description must be added to the configuration file **device\_info.hcs** defined by the HDF for drivers developed based on the HDF. The following is an example: 97 98 ``` 99 root { 100 device_info { 101 match_attr = "hdf_manager"; 102 template host { // Host template. If the node (for example, sample_host) that inherits the template uses default values in the template, the values of the node fields can be omitted. 103 hostName = ""; 104 priority = 100; 105 template device { 106 template deviceNode { 107 policy = 0; 108 priority = 100; 109 preload = 0; 110 permission = 0664; 111 moduleName = ""; 112 serviceName = ""; 113 deviceMatchAttr = ""; 114 } 115 } 116 } 117 sample_host :: host{ 118 hostName = "host0"; // Host name. The host node is used to store a certain type of drivers. 119 priority = 100; // Host startup priority (0-200). A larger value indicates a lower priority. The default value 100 is recommended. If the priorities are the same, the host loading sequence is random. 120 device_sample :: device { // Device node of sample 121 device0 :: deviceNode { // DeviceNode of the sample driver 122 policy = 1; // Driver service release policy. For details, see section Driver Service Management. 123 priority = 100; // Driver startup priority (0-200). A larger value indicates a lower priority. The default value 100 is recommended. If the priorities are the same, the device loading sequence is random. 124 preload = 0; // On-demand loading of the driver. For details, see "NOTE" at the end of this section. 125 permission = 0664; // Permission for the driver to create device nodes. 126 moduleName = "sample_driver"; // Driver name. The value of this field must be the same as the value of moduleName in the driver entry structure. 127 serviceName = "sample_service"; // Name of the service released by the driver. The name must be unique. 128 deviceMatchAttr = "sample_config"; // Keyword matching the private data of the driver. The value must be the same as that of match_attr in the private data configuration table of the driver. 129 } 130 } 131 } 132 } 133 } 134 ``` 135 136 - \(Optional\) Private configuration information of the driver 137 138 If the driver has private configurations, you can add a driver configuration file to fill in the default configuration information of the driver. When loading the driver, the HDF obtains the information and saves it in the **property** of **HdfDeviceObject**, and transfers it to the driver using **Bind** and **Init** \(see [1](#li35182436435)\). The following is an example of the driver configuration information: 139 140 ``` 141 root { 142 SampleDriverConfig { 143 sample_version = 1; 144 sample_bus = "I2C_0"; 145 match_attr = "sample_config"; // The value of this field must be the same as that of deviceMatchAttr in device_info.hcs. 146 } 147 } 148 ``` 149 150 After the configuration information is defined, you need to add the configuration file to the board-level configuration entry file **hdf.hcs**. \(You can use the DevEco to perform on-click configuration. For details, see the description about the driver development suite.\) The following is an example: 151 152 ``` 153 #include "device_info/device_info.hcs" 154 #include "sample/sample_config.hcs" 155 ``` 156 157 158 159> **NOTE:** 160>On-demand loading and sequential loading are supported. The detailed usage is as follows: 161>- On-demand loading 162> ``` 163> typedef enum { 164> DEVICE_PRELOAD_ENABLE = 0, 165> DEVICE_PRELOAD_ENABLE_STEP2, 166> DEVICE_PRELOAD_DISABLE, 167> DEVICE_PRELOAD_INVALID 168> } DevicePreload; 169> ``` 170> When the **preload** field in the configuration file is set to **0** \(**DEVICE\_PRELOAD\_ENABLE**\), the driver is loaded by default during system startup. When this field is set to **1** \(**DEVICE\_PRELOAD\_ENABLE\_STEP2**\), the driver is loaded after system startup if quick start is enabled; it is loaded during system startup otherwise. When this field is set to **2** \(**DEVICE\_PRELOAD\_DISABLE**\), the driver is not loaded by default during system startup and can be dynamically loaded later. If the driver service does not exist when a user-level application obtains the driver service \(for details about how to obtain the driver service, see [Driver Message Mechanism Management](driver-hdf-news.md)\), the HDF attempts to dynamically load the driver. 171>- Sequential loading \(drivers must be loaded by default\) 172> In the configuration file, the **priority** field \(the value is an integer ranging from 0 to 200\) indicates the priority of the host and driver. For drivers in different hosts, a smaller host priority value indicates a higher driver loading priority; for drivers in the same host, a smaller driver priority value indicates a higher driver loading priority. 173 174
