# Driver Subsystem ## Overview The 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. The 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: - Flexible framework capabilities 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. - Standardized driver APIs The OpenHarmony driver subsystem provides you with abundant and stable driver APIs, which are compatible with those of future-proof smartphones, tablets, smart TVs. - Component-based driver models 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. The subsystem also presets some template-based driver model components, such as the network device models. - Normalized configuration GUIs 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. You can use DevEco to manage driver projects, generate driver templates, and manage settings to make the development of OpenHarmony drivers easier. ## Architecture The OpenHarmony driver framework adopts the primary/secondary mode and is developed based on the framework, model, competence library, and tool. **Figure 1** Interaction between the driver and framework ![](figures/en-us_image_0000001053805078.png) - Driver framework stored in the **frameworks/core** directory - Loads and starts drivers. - Deploys and expands the driver framework flexibly through the object manager. - Driver models stored in the **frameworks/model** directory - Provides model-based driving capabilities, such as network device models. - Driver capability library stored in the **frameworks/ability** directory - Provides basic driver models, such as the I/O communication model. - Driver tools stored in the **frameworks\\tools** directory - Provides tools for HDI API conversion, and driver configuration and driver compilation. - Driver APIs stored in the **lite\\hdi** directory - Provides normalized driver APIs. - Support stored in the **frameworks/support** directory - Provides platform driver APIs and system APIs with normalized abstraction capabilities. ## Directory Structures **Table 1** Directory structure of the OpenHarmony driver framework

Directory	Description
hdf	Indicates the OpenHarmony driver framework.
hdf\frameworks	Provides the source code to develop the driver frameworks, driver models, and capability model libraries.
hdf\frameworks\ability	Provides functional capabilities for the driver development, such as the message model libraries.
hdf\frameworks\core	Provides the core code to implement the OpenHarmony driver framework.
hdf\frameworks\core\host	Provides functions of the driver host environment framework, including: 1. Loading and starting a driver, and dispatching device nodes. 2. Dispatching events. 3. Managing the internal power status. 4. Managing the common driver resource configurations.
hdf\frameworks\core\manager	Provides the management modules of the driver framework, including: 1. Driver API management module. 2. Driver configuration management module. 3. Device node management module. 4. Security management module. 5. Fault management module.
hdf\frameworks\core\shared	Provides shared code for the host and manager.
hdf\frameworks\model	Provides a universal framework model for drivers.
hdf\frameworks\model\network	Provides network device models for drivers.
hdf\frameworks\support\	Provides drivers with system APIs and hardware, such as GPIO, I2C, and SPI capabilities. Some interfaces can be migrated across platforms.
hdf\frameworks\support\osal	Provides platforms with common adaptation interfaces, such as memory, thread, and mutex.
hdf\frameworks\support\platform	Provides APIs that support the common hardware of platforms, such as GPIO, I2C, and SPI capabilities.
hdf\frameworks\tools	Provides the driver capability libraries, such as the tool that configures and compiles the HCS (HDF Configuration Source).
hdf\frameworks\utils	Provides basic data structures and algorithms.
hdf\lite\adapter	Adapts to kernel operation APIs and provides abstract APIs.
hdf\lite\include	Provides driver APIs for lightweight devices.
hdf\lite\hdi	Provides APIs of the OpenHarmony driver.

## Constraints None ## Use **Figure 2** Interaction between the driver and framework ![](figures/en-us_image_0000001052764349.png) Driver 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 result. Driver development based on the HDF consists of the following three parts: 1. Driver: develop the functions. 2. Information configuration: present the loading information of the driver. 3. Resource configuration: configure the hardware information of the driver. The driver mainly aims to develop the functions. The first part that catches your eyes is the driver entry, which is described through **DriverEntry** alignment. Three APIs are available, namely **bind**, **init**, and **release**. ``` struct HdfDriverEntry g_deviceSample = { .moduleVersion = 1, .moduleName = "sample_driver", .Bind = SampleDriverBind, .Init = SampleDriverInit, .Release = SampleDriverRelease, }; ``` **Bind**: This API is used to bind driver devices and its functions. ``` int32_t SampleDriverBind(struct HdfDeviceObject *deviceObject) { // TODO: Bind device service to device object. // And you can also initialize device resources here. return HDF_SUCCESS; } ``` **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 APIs based on the configuration file. If the driver fails to be initialized, the driver framework will automatically release the created device API. ``` int32_t SampleDriverInit(struct HdfDeviceObject *deviceObject) { // TODO: Init hardware or other resources here. return HDF_SUCCESS; } ``` **Release**: When you need to uninstall a driver, the drive framework calls this function to release the driver resources. Then, other internal resources will be released. ``` void SampleDriverRelease(struct HdfDeviceObject *deviceObject) { // Release all resources. return; } ``` ## Installation The 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. **Figure 3** OpenHarmony driver installation ![](figures/en-us_image_0000001053044331.png) ## Repositories Involved drivers\_hdf\_frameworks drivers\_hdf\_lite