1# Driver Subsystem<a name="EN-US_TOPIC_0000001052619216"></a> 2 3- [Overview](#section11660541593) 4- [Architecture](#section101721227145613) 5- [Directory Structure](#section1464106163817) 6- [Use](#section8496817141616) 7- [Installation](#section14778154275818) 8- [Repositories Involved](#section134812226297) 9 10## Overview<a name="section11660541593"></a> 11 12The 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. 13 14The 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: 15 16- Flexible framework capabilities 17 18 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. 19 20 21- Standardized driver APIs 22 23 The OpenHarmony driver subsystem provides you with abundant and stable driver APIs, which are compatible with those of future-proof smartphones, tablets, smart TVs. 24 25 26- Component-based driver models 27 28 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. 29 30 The subsystem also presets some template-based driver model components, such as the network device models. 31 32 33- Normalized configuration GUIs 34 35 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. 36 37 38You can use DevEco to manage driver projects, generate driver templates, and manage settings to make the development of OpenHarmony drivers easier. 39 40## Architecture<a name="section101721227145613"></a> 41 42The OpenHarmony driver framework adopts the primary/secondary mode and is developed based on the framework, model, competence library, and tool. 43 44**Figure 1** Driver subsystem architecture<a name="fig1077923710115"></a> 45 46 47- Driver framework stored in the **framework/core** directory 48 - Loads and starts drivers. 49 - Deploys and expands the driver framework flexibly through the object manager. 50 51- Driver model stored in the **framework/model** directory 52 - Provides model-based driving capabilities, such as network device models. 53 54- Driver capability library stored in the **framework/ability** directory 55 - Provides basic driver models, such as the I/O communication model. 56 57- Driver tools stored in the **framework/tools** directory 58 - Provides tools for HDI API conversion, and driver configuration and driver compilation. 59 60- Driver APIs stored in the **lite/hdi** directory 61 - Provides standardized driver APIs. 62 63- Support stored in the **framework/support** directory 64 - Provides platform driver APIs and system APIs with normalized abstraction capabilities. 65 66 67## Directory Structure<a name="section1464106163817"></a> 68 69``` 70drivers 71├── adapter # Adaptation code for differentiated platforms 72├── framework # Core code of the HDF 73└── peripheral # Peripheral driver code 74``` 75 76## Use<a name="section8496817141616"></a> 77 78**Figure 2** Interaction between the driver and framework<a name="fig1356181413429"></a> 79 80 81Driver 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. 82 83Driver development based on the HDF consists of the following three parts: 84 851. Driver: Develop the functions. 86 872. Information configuration: Present the loading information of the driver. 88 893. Resource configuration: Configure the hardware information of the driver. 90 91The driver mainly aims to develop the functions. 92 93The first part that catches your eyes is the driver entry, which is described through **DriverEntry**. 94 95Three APIs are available, namely **bind**, **init**, and **release**. 96 97``` 98struct HdfDriverEntry g_deviceSample = { 99 .moduleVersion = 1, 100 .moduleName = "sample_driver", 101 .Bind = SampleDriverBind, 102 .Init = SampleDriverInit, 103 .Release = SampleDriverRelease, 104}; 105``` 106 107**Bind**: This API is used to bind driver devices and its functions. 108 109``` 110int32_t SampleDriverBind(struct HdfDeviceObject *deviceObject) 111{ 112 // TODO: Bind device service to device object. 113 // And you can also initialize device resources here. 114 return HDF_SUCCESS; 115} 116``` 117 118**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. 119 120``` 121int32_t SampleDriverInit(struct HdfDeviceObject *deviceObject) 122{ 123 // TODO: Init hardware or other resources here. 124 return HDF_SUCCESS; 125} 126``` 127 128**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. 129 130``` 131void SampleDriverRelease(struct HdfDeviceObject *deviceObject) 132{ 133 // Release all resources. 134 return; 135} 136``` 137 138## Installation<a name="section14778154275818"></a> 139 140The 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. 141 142**Figure 3** Driver installation<a name="fig20119729154211"></a> 143 144 145## Repositories Involved<a name="section134812226297"></a> 146 147**Driver subsystem** 148 149[drivers\_framework](https://gitee.com/openharmony/drivers_framework/blob/master/README.md) 150 151[drivers\_adapter](https://gitee.com/openharmony/drivers_adapter/blob/master/README.md) 152 153[drivers\_adapter\_khdf\_linux](https://gitee.com/openharmony/drivers_adapter_khdf_linux/blob/master/README.md) 154 155[drivers\_peripheral](https://gitee.com/openharmony/drivers_peripheral/blob/master/README.md) 156 157
