Read the Android system source Scenario analysis notes (i)

android2.3 System driver module consists of kernel module, Hardware abstraction module, user call Module (JNI), kernel module and Linux, Hardware abstraction module need to define two structure: hw_module_t and hw_device_t.

hw_module_t contains the module ID, version number, signature, and a function pointer:

int open (struct hw_module_t* module, const char* ID, struct hw_device_t** device);

hw_device_t contains the version, the hw_module_t reference, and a function pointer:

int close (struct hw_device_t* device);

You must export a hal_module_sym symbol to reference the hw_module_t structure. These two structures can be customized by defining the two structures at the beginning of the custom structure (c idioms).

The user calls the module to load the hardware abstraction module through the Hw_get_module function.

int Hw_get_module (const char* ID, const struct hw_module_t** module);

The second parameter module receives the hardware abstraction module exported by the symbol hal_module_sym to the struct body.

The user invokes the module to open the device with the specified ID through its provided opening method, and the second parameter device receives a hw_device_t structure. The open function can return different hw_device_t structures depending on the device, and the close function may be different.

The user then invokes the module to call close or a custom function for closing or other operations through hw_device_t or a custom structure. Because it is at the user level, you need to modify ueventd.rc to modify the access rights of the device files provided by the kernel module.

Read the Android system source Scenario analysis notes (i)