To use third-party modules in the **third\_party** directory, you may need to adapt the modules. This section uses mbedTLS as an example to describe how to integrate the adaptation code with the OpenHarmony compilation framework. For the principles of mbedTLS and the specific logic of the adaptation code, see the adaptation guide on the mbedTLS official website.
1.编写适配层代码
1.<aname="li12446195633211"></a>Write the adaptation layer code.
Write the required adaptation layer code based on the mbedTLS adaptation guide. In this example, adaptation of the hardware random number is used for illustration, and the paths are relative to **third\_party/mbedtls**:
1. Copy the **include/mbedtls/config.h** file to the **ports** directory, and enable **MBEDTLS\_ENTROPY\_HARDWARE\_ALT** in the file.
2. In the **ports** directory, create the **entropy\_poll\_alt.c** file under **include** and implement the hardware random number API in **entropy\_poll.h**.
3. Add the path of the adapted **entropy\_poll\_alt.c** file to **mbedtls\_sources** in the **BUILD.gn** file.
4. Add the line **MBEDTLS\_CONFIG\_FILE** to **lite\_library\("mbedtls\_static"\)** in the **BUILD.gn** file to specify the path of the new configuration file.
You are advised to make the preceding modifications in a new **config.h** file or **_xxx_\_alt.c** file. Do not directly edit the code in the original file. Intrusive modifications may cause a large number of scattered conflicts during subsequent version updates, increasing the update maintenance costs.
The preceding adaptation is hardware-specific. Therefore, when uploading code to the library, you cannot directly store the code in the **third\_party/mbedtls** directory. Instead, you need to integrate the preceding modifications into a patch and inject the patch into the code for a build.
>The information about the product to which the patch is most recently applied will be recorded. Next time the build is performed, the previous patch is rolled back \(that is, **\`patch -p1 -R < xxx\`** is executed\). If the patch fails to be rolled back or a patch fails to be added, the build process is terminated. In this case, resolve the patch conflict and try again.
@@ -7,5 +7,5 @@ Drivers can be classified as platform drivers or device drivers. The platform dr
The HDF driver is designed to be used across OSs. The HDF driver framework provides strong support for the driver to achieve this goal. During HDF driver development, you are advised to use only the APIs provided by the HDF driver framework. Otherwise, the driver cannot be used across OSs. Before driver development, familiarize yourself with the [HDF](https://gitee.com/openharmony/docs/blob/master/en/device-dev/driver/hdf.md).
The Hardware Driver Foundation \(HDF\) is designed to work across OSs. The HDF driver framework provides strong support for drivers to achieve this goal. During HDF driver development, you are advised to use only the APIs provided by the HDF driver framework. Otherwise, the driver cannot be used across OSs. Before driver development, familiarize yourself with the [HDF](https://gitee.com/openharmony/docs/blob/master/en/device-dev/driver/hdf.md).
@@ -163,7 +163,7 @@ The WLAN driver is divided into two parts. One of the parts manages WLAN devices
As shown in [Figure 1](#fig155920160203), the left part manages Wi-Fi devices, and the right part manages WLAN traffic. The HDF WLAN framework abstracts these two parts. The porting process of the driver can be considered as the implementation of the APIs required by the two parts. These APIs are described as follows:
As shown in [Figure 1](#fig155920160203), the part on the left manages WLAN devices, and the part on the right manages WLAN traffic. The HDF WLAN framework abstracts these two parts. The porting process of the driver can be considered as the implementation of the APIs required by the two parts. These APIs are described as follows:
<tdclass="cellrowborder"valign="top"width="43.23432343234324%"headers="mcps1.1.4.1.3 "><pid="p26725514220"><aname="p26725514220"></a><aname="p26725514220"></a>Factory of the <strongid="b88841282246"><aname="b88841282246"></a><aname="b88841282246"></a>ChipDriver</strong>, which is used to support multiple WLAN ports of a chip.</p>
<tdclass="cellrowborder"valign="top"width="43.23432343234324%"headers="mcps1.1.4.1.3 "><pid="p26725514220"><aname="p26725514220"></a><aname="p26725514220"></a>Factory of the <strongid="b88841282246"><aname="b88841282246"></a><aname="b88841282246"></a>ChipDriver</strong>, which is used to support multiple WLAN interfaces of a chip.</p>
<tdclass="cellrowborder"valign="top"width="43.23432343234324%"headers="mcps1.1.4.1.3 "><pid="p26814555217"><aname="p26814555217"></a><aname="p26814555217"></a>Manages a specific WLAN port.</p>
<tdclass="cellrowborder"valign="top"width="43.23432343234324%"headers="mcps1.1.4.1.3 "><pid="p26814555217"><aname="p26814555217"></a><aname="p26814555217"></a>Manages a specific WLAN interface.</p>
<tdclass="cellrowborder"valign="top"width="43.23432343234324%"headers="mcps1.1.4.1.3 "><pid="p368195513213"><aname="p368195513213"></a><aname="p368195513213"></a>Communicates with the protocol stack, such as sending data and setting the status of network ports.</p>
<tdclass="cellrowborder"valign="top"width="43.23432343234324%"headers="mcps1.1.4.1.3 "><pid="p368195513213"><aname="p368195513213"></a><aname="p368195513213"></a>Communicates with the protocol stack, such as sending data and setting the status of network interfaces.</p>
</td>
</tr>
</tbody>
...
...
@@ -312,11 +312,11 @@ The porting procedure is as follows:
</tbody>
</table>
2. Compile a configuration file to describe the chips supported by the driver.
2. Create a configuration file to describe the chips supported by the driver.
Create a chip configuration file in the product configuration directory and save it to the source code path **//vendor/vendor\_name/product\_name/config/wifi/wlan\_chip\_chip\_name.hcs**.
The following is the file template:
The sample code is as follows:
```
root {
...
...
@@ -339,7 +339,7 @@ The porting procedure is as follows:
>Replace the values of **vendor\_name**, **product\_name**, and **chip\_name** in the path and file with the actual names.
>Set **vendorId** and **deviceId** to the actual vendor ID and chip ID, respectively.
3.Compile the configuration file and load the driver.
3.Edit the configuration file and load the driver.
All device information of the product is defined in the source code file **//vendor/vendor\_name/product\_name/config/device\_info/device\_info.hcs**. Modify the file and add configurations to the **device** named **device\_wlan\_chips** in the **host** of the **network** command. The sample code is as follows:
Create a platform driver in the source code directory **//device/vendor\_name/soc\_name/drivers**. If there is no repository for the vendor of your SoC, contact [sig-devboard](https://gitee.com/openharmony/community/blob/master/sig/sig-devboard/sig_devboard.md) to create one.
Create a platform driver in the source code directory **//device/vendor\_name/soc\_name/drivers**. If there is no repository for the vendor of your SoC, contact the [device SIG](https://gitee.com/openharmony/community/blob/master/sig/sig-devboard/sig_devboard.md) to create one.
The recommended directory structure is as follows:
...
...
@@ -31,9 +31,9 @@ device
The HDF creates driver models for all platform drivers. The main task of porting platform drivers is to inject instances into the models. You can find the definitions of these models in the source code directory **//drivers/framework/support/platform/include**.
This section uses the GPIO as an example to describe how to port the platform driver. The porting procedure is as follows:
The following uses the GPIO as an example to describe how to port the platform driver:
1. Creating a GPIO driver.
1. Create a GPIO driver.
Create the **soc\_name\_gpio.c** file in the source code directory **//device/vendor\_name/soc\_name/drivers/gpio**. The sample code is as follows:
...
...
@@ -70,7 +70,7 @@ This section uses the GPIO as an example to describe how to port the platform dr
{
// The GpioCntlrFromDevice method obtains the model instance registered in the init method from the abstract device object.
