首先我也非常感动有人研究 AOSP HAL
我当初掉进 AOSP 的坑也是从 HAL 开始
※ 引述《gn00618777 (非常念旧)》之铭言：
: 在asop内
: mydroid/hardware/libhardware/hardware.c 内的 hw_get_module function
: 原型是
: hw_get_module(const *id, hw_module_t **)
: 但在许多 android service 中会呼叫，并带入参数(如:
: camera_module_t、sensor_module_t)
: 在 service 内宣告一个 sensor_module_t 的变量 mSensorModule
: 呼叫 hw_get_module( * , (hw_module_t**)&mSensorModule);
: mSensorModule 结构里有包含 hw_module_t 的型态，mSensorModule
: 被强制作 hw_module_t 型态转换有什么用意吗?
从结论来说 你可以见识到 google 工程师 c/c++ 的怪物等级：
你可以观察一下 像 sensors_module_t, camera_module_t 这些 struct
他们有个共同特征：第一个 struct field 一定是 hw_module_t 型态
例如 sensors_module_t 他第一个 struct field 就是 "struct hw_module_t common;"
而假如 sensors_module_t 和 hw_module_t 长这样：
struct hw_module_t {
int id;
const char* name;
}
struct sensors_module_t{
struct hw_module_t common;
int foo;
int bar;
}
那其实在内存中你可以把它想成他会"摊开"成这样：
struct sensors_module_t {
int id;
const char* name;
int foo;
int bar
}
所以假如你有一个 sensors_module_t 型态的变量 sensorMod
那你依然可以呼叫 ((hw_module_t*)&sensorMod)->name
没错 老师说 struct 的 memory layout 不一定会一个 field 接着一个
可能会因 alignment 而有所调整 但因为 hw_module_t 必定是在第一个 field
(这是类似约定的规定 google没写出来是因为这件事只要给硬件厂知道就好)
所以不用担心 alignment 问题
这种手法看起来是不是很熟悉？ 没错 他们就是用 C 来模拟 C++ 的继承
为什么不直接用 C++? 疴...因为很多硬件工程师只会写C (X)
因为 C 许多性质都比较适合写底层的 code (O)
: 最后 mSensorModule 可以拿来呼叫mSensorModule->get_sensor_list() function
: mSensorModule不是已经被转换成 hw_module_t型态了? 他为啥可以呼叫
: sensors_module_t型态里面的 get_sensor_list fucntion?
: 谢谢指教..
其实 hw_get_module 的流程挺简单的：
丢给他你想要的硬件后 他会解析名称然后用 dlopen 加载适当的 .so file
也就是该硬件的实作 share library
而每个实作的硬件 shared library
礼面一定会有个变量 HAL_MODULE_INFO_SYM (这也是约定的)
像 sensor 的就在这边： http://goo.gl/186qAC
那个变量其实就是 XXX_module_t 的实作 在前面 dlopen 后会用 dlsym 去得到它
所以虽然你在 hw_get_module 那边已经把 mSensorModule 转型成 hw_module_t**
但重点就在这边：hw_module_t** 是指标的指标 也就是 dereference 第一次后
会是个 pointer, 在 C 语言中这种"输出型变量"很常见 所以显而易见的
这边就是输出个 hw_module_t* 这样的话因为是个指标 你就可以做一大堆奇怪的事了
说得更明确一点：sensors_module_t 的"实体" 在 share library 里面
所以就算你转成 hw_module_t* 但 sensors_module_t 的实体位址不会变啊
你依然存取得到他 以及呼叫他的函式