You need to sign in or sign up before continuing.
未验证 提交 e27c98b7 编写于 作者: O openharmony_ci 提交者: Gitee

!4910 #I57NUD完成

Merge pull request !4910 from Annie_wang/PR4000
......@@ -7,7 +7,7 @@ The Hardware Driver Foundation (HDF) is designed upon a component-based driver m
The figure below shows the HDF driver model.
**Figure 1** HDF driver model
**Figure 1** HDF driver model
![](figures/hdf-driver-model.png)
......@@ -16,7 +16,8 @@ The figure below shows the HDF driver model.
The HDF-based driver development involves driver implementation and configuration. The procedure is as follows:
1. Implement a driver.<br/>
1. Implement a driver.
Write the driver code and register the driver entry with the HDF.
- Writing the driver service code
......@@ -50,10 +51,8 @@ The HDF-based driver development involves driver implementation and configuratio
return;
}
```
- Registering the driver entry with the HDF
```
// Define a driver entry object. It must be a global variable of the HdfDriverEntry type (defined in hdf_device_desc.h).
struct HdfDriverEntry g_sampleDriverEntry = {
......@@ -68,11 +67,14 @@ The HDF-based driver development involves driver implementation and configuratio
HDF_INIT(g_sampleDriverEntry);
```
2. Build the driver.<br/>
- LiteOS<br/>
Modify the **Makefile** and **BUILD.gn** files.
2. Build the driver.
- LiteOS
Modify **makefile** and **BUILD.gn**.
- **Makefile**:<br/>
Use the **makefile** template provided by the HDF to compile the driver code.
......@@ -82,10 +84,10 @@ The HDF-based driver development involves driver implementation and configuratio
LOCAL_INCLUDE: = # Directory of the driver header files.
LOCAL_SRCS : = # Source code file of the driver.
LOCAL_CFLAGS : = # Custom compilation options.
include $(HDF_DRIVER) # Import the makefile template to complete the compilation.
include $(HDF_DRIVER) # Import the Makefile template to complete the build.
```
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.
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:
```
......@@ -93,7 +95,8 @@ The HDF-based driver development involves driver implementation and configuratio
LIB_SUBDIRS += # Directory in which Makefile is located.
```
- **BUILD.gn**:<br/>
- **BUILD.gn**:
Add **BUILD.gn**. The content of **BUILD.gn** is as follows:
......@@ -126,7 +129,9 @@ The HDF-based driver development involves driver implementation and configuratio
]
}
```
- Linux<br/>
- 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**.
......@@ -149,11 +154,13 @@ The HDF-based driver development involves driver implementation and configuratio
```
3. Configure the driver.<br/>
The HDF Configuration Source (HCS) contains the source code of HDF configuration. For details about the HCS, see [Configuration Management](../driver/driver-hdf-manage.md).
The driver configuration consists of the driver device description defined by the HDF and the private driver configuration.
- (Mandatory) Setting the driver device description<br/>
The HDF loads a driver based on the driver device description defined by the HDF. Therefore, the driver device description must be added to the **device_info.hcs** file defined by the HDF. The following is an example:
......@@ -185,12 +192,12 @@ The HDF-based driver development involves driver implementation and configuratio
caps = ["DAC_OVERRIDE", "DAC_READ_SEARCH"]; // Linux capabilities of the user-mode process.
device_sample :: device { // Sample device node.
device0 :: deviceNode { // DeviceNode of the sample driver.
policy = 1; // Policy for providing the driver service. For details, see Driver Service Management.
policy = 1; // Policy for publishing the driver service. For details, see Driver Service Management.
priority = 100; // Driver startup priority (0-200). A smaller value indicates a higher priority. The default value 100 is recommended. The drivers with the same priority start based on the time when the priority was configured. The driver configured first starts first.
preload = 0; // The loading mode of the driver is on-demand loading. For details, see "NOTE" at the end of this document.
permission = 0664; // Permission for the driver to create a device node.
moduleName = "sample_driver"; // Driver name. The value must be the same as that of moduleName in the HdfDriverEntry structure.
serviceName = "sample_service"; // Name of the service provided by the driver. The service name must be unique.
moduleName = "sample_driver"; // Driver name. The value of this field must be the same as that of moduleName in the HdfDriverEntry structure.
serviceName = "sample_service"; // Name of the service published by the driver. The service name must be unique.
deviceMatchAttr = "sample_config"; // Keyword for 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.
}
}
......@@ -201,19 +208,21 @@ The HDF-based driver development involves driver implementation and configuratio
![icon-note.gif](../public_sys-resources/icon-note.gif) **NOTE**<br>
- **uid**, **gid**, and **caps** are startup parameters for user-mode drivers only.
- According to the principle of least privilege for processes, **uid** and **gid** do not need to be configured for service modules. In the preceding example, **uid** and **gid** are left empty (granted with the common user rights) for sample_host.
- If you need to set **uid** and **gid** to **system** or **root** due to service requirements, contact security experts for review.
- The process UIDs are configured in **base/startup/init_lite/services/etc/passwd**, and the process GIDs are configured in **base/startup/init_lite/services/etc/group**. For details, see [Adding a System Service User Group]( https://gitee.com/openharmony/startup_init_lite/wikis).
- If CAP_DAC_OVERRIDE needs to be configured for a service module, enter **caps = ["DAC_OVERRIDE"]** instead of **caps = ["CAP_DAC_OVERRIDE"]**.
- The process UIDs are configured in **base/startup/init_lite/services/etc/passwd**, and the process GIDs are configured in **base/startup/init_lite/services/etc/group**. For details, see [Adding a System Service User Group]( https://gitee.com/openharmony/startup_init_lite/wikis).
- If CAP_DAC_OVERRIDE needs to be configured for a service module, enter **caps = ["DAC_OVERRIDE"]** instead of **caps = ["CAP_DAC_OVERRIDE"]**.
- (Optional) Setting driver private information<br/>
If the driver has private configuration, add a driver configuration file to set default driver configuration. When loading the driver, the HDF obtains and saves the driver private information in **property** of **HdfDeviceObject**, and passes the information to the driver using **Bind()** and **Init()** (see step 1).
The following is an example of the driver private configuration:
```
root {
SampleDriverConfig {
......@@ -228,14 +237,13 @@ The HDF-based driver development involves driver implementation and configuratio
The following is an example:
```
#include "device_info/device_info.hcs"
#include "sample/sample_config.hcs"
```
> ![icon-note.gif](../public_sys-resources/icon-note.gif) **NOTE**<br>
> ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE**<br/>
> Drivers can be loaded on demand or in sequence.
>
> - On-demand loading
......@@ -256,4 +264,4 @@ The HDF-based driver development involves driver implementation and configuratio
> 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, the HDF attempts to dynamically load the driver if the driver service does not exist. For more details, see [Driver Messaging Mechanism](driver-hdf-message-management.md).
>
> - Sequential loading (**preload** set to **0 (DEVICE_PRELOAD_ENABLE)**)<br/>
> In the configuration file, the **priority** fields (value range: 0 to 200) determines the loading sequence of a host and a 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.
> In the configuration file, the **priority** field (value range: 0 to 200) determines the loading sequence of a host and a 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.
......@@ -53,7 +53,7 @@ An attribute is the minimum, independent configuration unit. The syntax is as fo
attribute_name = value;
```
- **attribute_name** is a case-sensitive string of letters, digits, and underscores (_) and must start with a letter or underscore (_).
- **attribute_name** is a case-sensitive string of letters, digits, and underscores (\_) and must start with a letter or underscore (_).
- The **value** can be in any of the following formats:
......@@ -75,7 +75,7 @@ A node is a set of attributes. The syntax is as follows:
}
```
- **node_name** is a case-sensitive string of letters, digits, and underscores (_) and must start with a letter or underscore (_).
- **node_name** is a case-sensitive string of letters, digits, and underscores (\_) and must start with a letter or underscore (_).
- No semicolon (;) is required after the curly brace ({) or (}).
......@@ -173,7 +173,6 @@ You can reference the content of a node to modify the content of another node. T
In this statement, the content of **node** is referenced to modify the content of **source_node**.
Example:
```
root {
module = "sample";
......@@ -232,7 +231,6 @@ This statement replicates the attributes of the **source_node** node to define *
Example:
```
root {
module = "sample";
......@@ -263,7 +261,7 @@ root {
In this example, the **bar** node contains **attr_0** and **attr_1** attributes, and the modification of the **attr_0** attribute in the **bar** node does not affect the **foo** node.
You do not need to specify the path of the **foo** node if the **foo** node and the **bar** node are of the same level. Otherwise, specify the absolute path of **foo**. For details, see [Reference Modification](referencemodification).
You do not need to specify the path of the **foo** node if the **foo** node and the **bar** node are of the same level. Otherwise, specify the absolute path of **foo**. For details, see [Reference Modification](#reference-modification).
### Delete
......@@ -272,7 +270,6 @@ You can use the keyword **delete** to delete unnecessary nodes or attributes fro
Example:
```
// sample2.hcs
root {
......@@ -318,7 +315,6 @@ In this statement, the value of **attribute** is a referenced to the node. Durin
Example:
```
node1 {
attributes;
......@@ -328,7 +324,7 @@ node2 {
}
```
Or
or
```
......@@ -349,7 +345,6 @@ If a node is defined using the keyword **template**, its child nodes inherit fro
Example:
```
root {
module = "sample";
......
......@@ -232,7 +232,7 @@ int main()
}
```
> ![icon-note.gif](../public_sys-resources/icon-note.gif) **NOTE**<br/>
> ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE**<br/>
> The user-mode application uses the message sending API of the HDF, and the compilation of the user-mode application depends on the dynamic libraries **hdf_core** and **osal** provided by the HDF. Therefore, you need to add the following dependencies to the .gn file:
>
> deps = [
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册