1# Driver<a name="EN-US_TOPIC_0000001052619216"></a> 2 3## Overview<a name="section11660541593"></a> 4 5The OpenHarmony driver subsystem is constructed using the C object-oriented programming \(OOP\). It provides a unified driver platform through platform decoupling, kernel decoupling, and compatible kernels. This unified driver architecture platform is designed to provide a more precise and efficient development environment, where you develop a driver that can be deployed on different systems supporting HDF. 6 7The OpenHarmony driver subsystem provides the following key features and capabilities to shorten the driver development period and make third-party device driver integration much easier: 8 9- Flexible framework capabilities 10 11 Based on the traditional driver framework, the OpenHarmony driver subsystem builds flexible framework capabilities to deploy terminal products with the capacity ranging from hundreds KB to hundreds MB of memory. 12 13 14- Standardized driver APIs 15 16 The OpenHarmony driver subsystem provides you with abundant and stable driver APIs, which are compatible with those of future-proof smartphones, tablets, smart TVs. 17 18 19- Component-based driver models 20 21 The OpenHarmony driver subsystem supports component-based driver models. It provides more refined driver management to dismantle components, enabling you to focus on the interaction between the hardware and driver. 22 23 The subsystem also presets some template-based driver model components, such as the network device models. 24 25 26- Normalized configuration GUIs 27 28 The OpenHarmony driver subsystem provides a unified configuration GUI and a cross-platform tool for configuration conversion and generation to implement seamless switchover across platforms. 29 30 31You can use DevEco to manage driver projects, generate driver templates, and manage settings to make the development of OpenHarmony drivers easier. 32 33## Architecture<a name="section101721227145613"></a> 34 35The OpenHarmony driver framework adopts the primary/secondary mode and is developed based on the framework, model, competence library, and tool. 36 37**Figure 1** Driver subsystem architecture<a name="fig1077923710115"></a> 38 39 40- Driver framework stored in the **framework/core** directory 41 - Loads and starts drivers. 42 - Deploys and expands the driver framework flexibly through the object manager. 43 44- Driver model stored in the **framework/model** directory 45 - Provides model-based driving capabilities, such as network device models. 46 47- Driver capability library stored in the **framework/ability** directory 48 - Provides basic driver models, such as the I/O communication model. 49 50- Driver tools stored in the **framework/tools** directory 51 - Provides tools for HDI API conversion, and driver configuration and driver compilation. 52 53- Driver APIs stored in the **lite/hdi** directory 54 - Provides standardized driver APIs. 55 56- Support stored in the **framework/support** directory 57 - Provides platform driver APIs and system APIs with normalized abstraction capabilities. 58 59 60## Directory Structure<a name="section1464106163817"></a> 61 62``` 63drivers 64├── adapter # Adaptation code for differentiated platforms 65├── framework # Core code of the HDF 66└── peripheral # Peripheral driver code 67``` 68 69## Use<a name="section8496817141616"></a> 70 71**Figure 2** Interaction between the driver and framework<a name="fig1356181413429"></a> 72 73 74Driver loading is mostly done by the driver framework, and you only need to register and configure required APIs. The driver framework will load and initialize the driver based on the parsing content. 75 76Driver development based on the HDF consists of the following three parts: 77 781. Driver: Develop the functions. 79 802. Information configuration: Present the loading information of the driver. 81 823. Resource configuration: Configure the hardware information of the driver. 83 84The driver mainly aims to develop the functions. 85 86The first part that catches your eyes is the driver entry, which is described through **DriverEntry**. 87 88Three APIs are available, namely **bind**, **init**, and **release**. 89 90``` 91struct HdfDriverEntry g_deviceSample = { 92 .moduleVersion = 1, 93 .moduleName = "sample_driver", 94 .Bind = SampleDriverBind, 95 .Init = SampleDriverInit, 96 .Release = SampleDriverRelease, 97}; 98``` 99 100**Bind**: This API is used to bind driver devices and its functions. 101 102``` 103int32_t SampleDriverBind(struct HdfDeviceObject *deviceObject) 104{ 105 // TODO: Bind device service to device object. 106 // And you can also initialize device resources here. 107 return HDF_SUCCESS; 108} 109``` 110 111**Init**: When devices are successfully bound, the framework calls **Init** to initialize the driver. After initialization is complete, the driver framework will determine whether to create external service interfaces based on the configuration file. If the driver fails to be initialized, the driver framework will automatically release the created device interface. 112 113``` 114int32_t SampleDriverInit(struct HdfDeviceObject *deviceObject) 115{ 116 // TODO: Init hardware or other resources here. 117 return HDF_SUCCESS; 118} 119``` 120 121**Release**: When you need to uninstall a driver, the driver framework calls this function to release the driver resources. Then, other internal resources will be released. 122 123``` 124void SampleDriverRelease(struct HdfDeviceObject *deviceObject) 125{ 126 // Release all resources. 127 return; 128} 129``` 130 131## Installation<a name="section14778154275818"></a> 132 133The OpenHarmony driver is mainly deployed in the kernel space using the static link mode. It is compiled and packed with the kernel subsystem and system image. 134 135**Figure 3** Driver installation<a name="fig20119729154211"></a> 136 137 138## Repositories Involved<a name="section134812226297"></a> 139 140**Driver subsystem** 141 142[drivers\_framework](https://gitee.com/openharmony/drivers_framework/blob/master/README.md) 143 144[drivers\_adapter](https://gitee.com/openharmony/drivers_adapter/blob/master/README.md) 145 146[drivers\_adapter\_khdf\_linux](https://gitee.com/openharmony/drivers_adapter_khdf_linux/blob/master/README.md) 147 148[drivers\_peripheral](https://gitee.com/openharmony/drivers_peripheral/blob/master/README.md) 149 150
