PCB Blog - Specific implementation methods capabilities of HDI's IPC

An important function of the  HDI driver framework is to provide a stable and unified hardware interface for the system, so as to ensure that system services can run on different hardware without additional adaptation. HDI (Hardware Device Interfaces) is designed for this purpose.

 HDI is a high-level abstract interface for hardware functions. After the definition of the HDI interface, various peripherals will only be changed under HDI compatibility rules to ensure the stability of the interface. The specific driver implementation does not need to define the HDI interface repeatedly, but only needs to be implemented on demand to access the system functions.

On OpenHarmony systems of different magnitudes, HDI has two deployment modes: IPC mode and pass-through mode.

On the lightweight OpenHarmony system, in order to reduce the system performance load, HDI is implemented as a user mode shared library, which is directly loaded by the system service into its own process for function call. HDI  implementation encapsulates the specific user kernel interaction process. When the driver needs to be accessed, use IO Service Request to call the message to the kernel driver through system call.

On the OpenHarmony system, HDI is deployed as an independent service process. The system service only loads the HDI client into its own process. The actual business runs in an independent process. The client interacts with the server through IPC, facilitating architecture decoupling and permission management.

 HDI  interface implementation

The pass through mode is a function implementation mode, which can be implemented without the support of other components, regardless of calling or implementation. Here we will focus on the implementation of  IPC mode.

HDI release

The HDI IPC mode is based on the general model of the OpenHarmony system communication framework. However, because the driver often involves low-level operations and multi-system migration scenarios, it is written in C language. Therefore, the driver framework also provides the basic components of the HDI service implemented in C language, while the implementation mainly uses the system communication framework components.

HDI service publishing is implemented based on UHDF (user mode HDF driver framework). The general service publishing implementation is as follows.

1. Drive entrance

int SampleDriverBind（struct HdfDeviceObject *deviceObject）{ HDF_LOGE（“SampleDriverBind enter！”）;  static struct IDeviceIoService testService={. Dispatch=SampleServiceDispatch,//Service callback interface}; deviceObject-》service = &testService;  return HDF_ SUCCESS;}  int SampleDriverInit（struct HdfDeviceObject *deviceObject）{ HDF_LOGE（“SampleDriverInit enter”）; return HDF_SUCCESS;}  void SampleDriverRelease（struct HdfDeviceObject *deviceObject）{ HDF_LOGE（“SampleDriverRelease enter”）; return;}  struct HdfDriverEntry g_ sampleDriverEntry = { .moduleVersion = 1， .moduleName = “sample_driver”， .Bind = SampleDriverBind， .Init = SampleDriverInit， .Release = SampleDriverRelease，};

HDF_ INIT（g_sampleDriverEntry）;

First, you need to add a UHDF driver to publish the IoService service. The IoService device service is the HDI service entity. The implementation mode is consistent with the KHDF drive.

2. Implement the service response interface

int32_ t SampleServiceOnRemoteRequest（struct HdfDeviceIoClient *client， int cmdId， struct HdfSBuf *data， struct HdfSBuf *reply）{ switch （cmdId） { case SAMPLE_SERVICE_PING： return SampleServiceStubPing（client， data， reply）; … … default： HDF_LOGE（“SampleServiceDispatch： not support cmd %d”， cmdId）; return HDF_ERR_INVALID_PARAM; }} static int32_ t SampleServiceDispatch（struct HdfDeviceIoClient *client， int cmdId， struct HdfSBuf *data， struct HdfSBuf *reply）{ return SampleServiceOnRemoteRequest（client， cmdId， data， reply）;}

When HDI call is received, the service response interface "SampleServiceDispatch" will be called.

The client caller object is not supported in the user mode driver

CmdId calls the command word, which is used to distinguish the called API.The data call input parameter serialization object is encapsulated in the C language of the parcel object in the IPC call scenario. The input parameter needs to be obtained from the data object using the serialization interface before use. The reply calls out the parameter object, and the information returned to the call needs to be written into the serialized object. If the C++implementation client can use the following interface to convert the sbuf object to the parcel object, then the operation can be performed:

3. UHDF drive configuration

platform ：： host { hostName = “sample_host”; priority = 50; sample_device ：： device { device0 ：： deviceNode { policy = 2; priority = 100; moduleName = “libsample_driver.z.so”; serviceName = “sample_driver_service”; } }}

Parameter description:

host A host node is an independent process. If you need an independent process, add your own host node.Policy service publishing policy, HDI service is set to 2.ModuleName Driver Implementation Library Name.ServiceName Service name, please keep it globally unique.Because HDI Service C and C++implementations use different IPC components and object oriented implementations, there are some differences in specific implementations. In order to support HDI implementation, the UHDF framework provides the following basic components (only for C language HDI implementation):

SBuf is a tool object that supports both KHDF and UHDF to drive the serialization of IoService messages. In the UHDF IPC communication scenario, SBuf can convert with the system IPC framework serialization object MessageParcel object (only C++is supported) to achieve IPC interworking between C and C++.

Common APIs are as follows:

struct HdfSBuf; struct HdfSbufImpl; struct HdfRemoteService;

All the IPC above interfaces have corresponding write interfaces, which are not listed one by one. Please refer to the official website HDI reference document.