The 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](#fig3580184214210) shows the HDF driver model.
The HDF is designed based on the component-based driver model. This model allows refined driver management and normalizes driver development and deployment. 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](#fig3580184214210) shows the HDF driver model.
## How to Develop<a name="section1969312275533"></a>
Driver development based on the HDF consists of two parts: driver implementation and driver configuration. The details are as follows:
Driver development based on the HDF involves driver implementation and driver configuration. The development procedure is as follows:
1.<aname="li35182436435"></a>Implement driver.
1.<aname="li35182436435"></a>Implement a driver.
To implement a driver, compile driver service code and register a driver entry.
...
...
@@ -64,34 +64,94 @@ Driver development based on the HDF consists of two parts: driver implementation
HDF_INIT(g_sampleDriverEntry);
```
2. Compile the driver code.
- Use the **Makefile** template provided by the HDF to compile the driver code.
2. Build the driver.
```
include $(LITEOSTOPDIR)/../../drivers/adapter/lite/khdf/lite.mk # (Mandatory) Import the predefined content of the HDF.
MODULE_NAME := # Generated result file
LOCAL_INCLUDE: = # Header file directory of the driver
LOCAL_SRCS : = # Source code file of the driver
LOCAL_CFLAGS : = # Custom compilation options
include $(HDF_DRIVER) # Import the template Makefile to complete compilation.
```
- LiteOS
- 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:
Modify **makefile** and **BUILD.gn**:
```
LITEOS_BASELIB += -lxxx # Static library generated through linking
LIB_SUBDIRS += # Directory of Makefile
```
* makefile:
Use the **makefile** template provided by the HDF to compile the driver code.
```
include $(LITEOSTOPDIR)/../../drivers/adapter/khdf/liteos/lite.mk # Import the content predefined by the HDF. This operation is mandatory.
MODULE_NAME := # File to be generated.
LOCAL_INCLUDE: = # Header file directory of the driver.
LOCAL_SRCS : = # Source code file of the driver.
LOCAL_CFLAGS : = # Custom compilation options.
include $(HDF_DRIVER) # Import the makefile template to complete the compilation.
```
Add the path of the generated file to **hdf_lite.mk** in the **drivers/adapter/khdf/liteos** directory to link the file to the kernel image. The following is an example:
```
LITEOS_BASELIB += -lxxx # Static library generated by the link.
LIB_SUBDIRS += # Directory in which the driver code makefile is located.
```
* BUILD.gn:
Add **BUILD.gn**. The content of **BUILD.gn** is as follows:
public_configs = [ ":public" ] # Configuration applied to dependencies
}
config("public") {# Configuration of the dependencies
include_dirs = [
"xxx/xxx/xxx", # Directory of the dependency header file.
]
}
```
Add the directory where the **BUILD.gn** file of the driver is located to **/drivers/adapter/khdf/liteos/BUILD.gn**.
```
group("liteos") {
public_deps = [ ":$module_name" ]
deps = [
"xxx/xxx", # Directory where the BUILD.gn of the driver is located. It is a relative path to /drivers/adapter/khdf/liteos.
]
}
```
- Linux
To define the driver control macro, add the **Kconfig** file to the driver directory **xxx** and add the path of the **Kconfig** file to **drivers/adapter/khdf/linux/Kconfig**.
```
source "drivers/hdf/khdf/xxx/Kconfig" # Kernel directory to which the HDF module is soft linked.
```
Add the driver directory to **drivers/adapter/khdf/linux/Makefile**.
```
obj-$(CONFIG_DRIVERS_HDF) += xxx/
```
Add a **Makefile** to the driver directory **xxx** and add code compiling rules of the driver to the **Makefile** file.
```
obj-y += xxx.o
```
3. Configure the driver.
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).
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).
The driver configuration consists of the driver device description defined by the HDF and private driver configuration information.
- \(Mandatory\) Driver device description
- (Mandatory) Driver device description
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:
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:
```
root {
...
...
@@ -165,7 +225,6 @@ Driver development based on the HDF consists of two parts: driver implementation
> DEVICE_PRELOAD_INVALID
> } DevicePreload;
> ```
> 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-message-management.md)\), the HDF attempts to dynamically load the driver.
> If the **preload** field in the configuration file is set to **0** (DEVICE\_PRELOAD\_ENABLE), the driver is loaded by default during the system boot process. If **preload** is set to **1** (DEVICE\_PRELOAD\_ENABLE\_STEP2), the driver is loaded after a quick start is complete if the system supports quick start. If the system does not support quick start, the value **1** has the same meaning as DEVICE\_PRELOAD\_ENABLE. If **preload** is set to **2** (DEVICE\_PRELOAD\_DISABLE), the driver is dynamically loaded instead of being loaded during the system boot process. When a user-mode process requests the driver service (for details, see [Driver Message Mechanism Management](driver-hdf-news.md)), the HDF attempts to dynamically load the driver if the driver service does not exist.
>- Sequential loading \(drivers must be loaded by default\)
> 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.
