update docs

Signed-off-by: NAnnie_wang <annie.wangli@huawei.com>

en/application-dev/database/database-distributedobject-guidelines.md

@@ -148,19 +148,19 @@ The following example shows how to implement a distributed data object synchroni
 8. Subscribe to the status (online/offline) changes of the distributed data object. A callback will be invoked to report the status change when the target distributed data object goes online or offline.
    The sample code is as follows:
    ```js
-    function statusCallback(sessionId, networkid, status) {
+    function statusCallback(sessionId, networkId, status) {
       this.response += "status changed " + sessionId + " " + status + " " + networkId;
     }
    
-    local_object.on("status", this.changeCallback);
+    local_object.on("status", this.statusCallback);
    ```
 9. Unsubscribe from the status changes of the distributed data object. You can specify the callback to unsubscribe from. If you do not specify the callback, all status change callbacks will be unsubscribe from. 
    
-    The sample code is as follows:
-   ```js
-   // Unsubscribe from changeCallback.
-   local_object.off("status", changeCallback);
-   // unsubscribe from all status change callbacks.
+  The sample code is as follows:
+  ```js
+   // Unsubscribe from statusCallback.
+   local_object.off("status", statusCallback);
+   // Unsubscribe from all status change callbacks.
    local_object.off("status");
    ```
 10. Remove a distributed data object from the synchronization network. After the distributed data object is removed from the network, the data changes on the local end will not be synchronized to the remote end.

en/device-dev/driver/driver-hdf-development.md

@@ -253,7 +253,7 @@ The HDF-based driver development involves driver implementation and configuratio
 >
 >   If **preload** is set to **1 (DEVICE_PRELOAD_ENABLE_STEP2)**, the driver is loaded after a quick start is complete. 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, the HDF attempts to dynamically load the driver if the driver service does not exist.  For more details, see [Driver Message Mechanism Management](driver-hdf-message-management.md).
+>   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.

en/device-dev/driver/driver-hdf-overview.md

-# HDF Overview<a name="EN-US_TOPIC_0000001051611604"></a>
+# HDF Overview
 
-## Introduction<a name="section0649162112376"></a>
 
-The Hardware Driver Foundation \(HDF\) provides the following driver framework capabilities: driver loading, driver service management, and driver message mechanism. This unified driver architecture platform is designed to provide a more precise and efficient development environment, where you can perform one-time development and multi-system deployment.
+## Introduction
 
-## Driver Loading<a name="section68701942154319"></a>
+The Hardware Driver Foundation (HDF) provides driver framework capabilities including driver loading, driver service management, and driver messaging mechanism. It strives to build a unified driver architecture platform to provide a more precise and efficient development environment, where you can perform one-time development for multi-device deployment.
 
-Both on-demand loading and sequential loading are supported.
 
--   On-demand loading
+## Driver Loading
 
-    Drivers can be loaded by default during the operating system \(OS\) startup or be loaded dynamically after the OS startup.
+The HDF supports the following loading modes:
 
--   Sequential loading
+- On-demand loading
+  The driver is loaded by default during the operating system (OS) boot process or dynamically loaded after OS is started.
 
-    Drivers can be loaded based on their priorities during the OS startup.
+- Sequential loading
+  The driver is loaded based on its priority during the OS boot process.
 
 
-## Driver Service Management<a name="section12453133414412"></a>
+## Driver Service Management
 
-The HDF centrally manages driver services. You can directly obtain a specified driver service by using the API provided by the HDF.
+The HDF allows centralized management of driver services. You can obtain a driver service by using the API provided by the HDF.
 
-## Driver Message Mechanism<a name="section129410710451"></a>
 
-The HDF provides a unified driver message mechanism, which allows message interactions between user-level applications and kernel-level drivers.
+## Driver messaging mechanism
 
+The HDF provides a unified driver messaging mechanism, which allows messages to be exchanged between user-mode applications and kernel-mode drivers.

en/device-dev/driver/driver-hdf-sample.md

-# HDF Development Example<a name="EN-US_TOPIC_0000001052451677"></a>
+# HDF Development Example
 
-The following example shows how to add driver configuration, compile the driver code, and implement interaction between the user-state applications and the driver.
 
-## Adding Configuration<a name="section27261067111"></a>
+The following is a HDF-based driver development example.
 
-Add the driver configuration to the HDF configuration file \(for example, **vendor/hisilicon/xxx/hdf_config/device\_info**\). 
 
-Example:
+## Adding Driver Configuration
 
+Add the driver configuration to the HDF configuration file, for example, **vendor/hisilicon/xxx/hdf_config/device_info**.
+
+  
 ```
 root {
     device_info {
@@ -44,10 +45,12 @@ root {
 }
 ```
 
-## Compiling the Driver Code<a name="section177988005"></a>
 
-The following is the sample driver code compiled based on HDF (for details, see [Driver Development](driver-hdf-development.md)):
+## Writing the Driver Code
+
+Write the driver code based on the HDF. For more details, see [Driver Development](../driver/driver-hdf-development.md).
 
+  
 ```
 #include <fcntl.h>
 #include <sys/stat.h>
@@ -79,7 +82,7 @@ int32_t HdfSampleDriverDispatch(
 
 void HdfSampleDriverRelease(struct HdfDeviceObject *deviceObject)
 {
-    // Release resources here
+    // release resources here
     return;
 }
 
@@ -116,10 +119,12 @@ struct HdfDriverEntry g_sampleDriverEntry = {
 HDF_INIT(g_sampleDriverEntry);
 ```
 
-## Compiling the Code for Interaction<a name="section6205173816412"></a>
 
-The following is the sample code compiled based on HDF for interaction between the driver and user-state applications. You can place the code in **drivers/adapter/uhdf** for compilation. For details about the **build.gn** file, see **drivers/framework/sample/platform/uart/dev/build.gn**.
+## Implementing Interaction Between the Application and the Driver 
+
+Write the code for interaction between the user-mode application and the driver. Place the code in the **drivers/adapter/uhdf** directory for compilation. For details about **build.gn**, see **drivers/framework/sample/platform/uart/dev/build.gn**.
 
+  
 ```
 #include <fcntl.h>
 #include <sys/stat.h>
@@ -227,9 +232,13 @@ int main()
 }
 ```
 
->![](../public_sys-resources/icon-note.gif) **NOTE:** 
->The code compilation of user-state applications depends on the dynamic libraries **hdf\_core** and **osal** provided by HDF because user-state applications use the message sending interface of HDF. In the GN file, add the following dependencies:
->deps = \[
->"//drivers/adapter/uhdf/manager:hdf\_core",
->"//drivers/adapter/uhdf/posix:hdf\_posix\_osal",
->\]
+> ![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 = [
+> 
+> "//drivers/adapter/uhdf/manager:hdf_core",
+> 
+> "//drivers/adapter/uhdf/posix:hdf_posix_osal",
+> 
+> ]

en/readme/Security.md

@@ -11,7 +11,7 @@ Its functions include application integrity verification, application permission
 
 **Figure 1** Security subsystem architecture<a name="fig4460722185514"></a> 
 
-![](figures/security-architecture.png)
+![](figures/security_subsustem_architecture.png)
 
 The security subsystem consists of the following functional modules: