android中hw_get_module函数分析

这个函数的主要功能是根据模块ID寻找硬件模块动态链接库德地址,然后调用load去打开动态链接库并从中获取硬件模块结构体地址。具体的源码如下:

代码@/hardware/libhardware/hardware.c

int hw_get_module(const char *id, const struct hw_module_t **module)

120 {

121     int status;

122     int i;

123     const struct hw_module_t *hmi = NULL;

124     char prop[PATH_MAX];

125     char path[PATH_MAX];

    /* Loop through the configuration variants looking for a module */

135     for (i=0 ; i<HAL_VARIANT_KEYS_COUNT+1 ; i++) {

/*

*这个地方我们来看一下下面将要用到的一个数组variant_keys,因为HAL_VARIANT_KEYS_COUNT这个就是

*数组variant_keys的大小。

*

*44 static const char *variant_keys[] = {

* 45     "ro.hardware",  /* This goes first so that it can pick up a different

* 46                        file on the emulator. */

* 47     "ro.product.board",

* 48     "ro.board.platform",

*  49     "ro.arch"

* 50 };

*这里我们记住这个数组,下面我就将用到它。 

*/

136         if (i < HAL_VARIANT_KEYS_COUNT) {

137             if (property_get(variant_keys[i], prop, NULL) == 0) {

138                 continue;

139             }

/*

*这个地方prop得到的就似乎相应的权限,variant_keys[i]对应的如下:

*

*trout\msm7k\ARMV6就是这三个值,那个ro.hardware没有找到。这个地方我也是看注册的,没有弄懂

*知道的同学指教一些,谢谢。

*/

140             snprintf(path, sizeof(path), "%s/%s.%s.so",//把相应的路径及文件名保存到path中

141                     HAL_LIBRARY_PATH, id, prop);

/*

*看到没有,这个地方其实就是把HAL_LIBRARY_PATH/id.***.so保存到path中,其中***就是上面我们所分析的variant_keys各个元素所对应的值。

*/

142         } else {

/*

*这个地方就体现了为什么我们上面for循环用的是HAL_VARIANT_KEYS_COUNT+1而不是*HAL_VARIANT_KEYS_COUNT。因为我们在最后还有加载一个default的属性。

*/

143             snprintf(path, sizeof(path), "%s/%s.default.so",

144                     HAL_LIBRARY_PATH, id);

145         }

146         if (access(path, R_OK)) {

147             continue;

148         }

149         /* we found a library matching this id/variant */

150         break;

151     }

152

153     status = -ENOENT;

154     if (i < HAL_VARIANT_KEYS_COUNT+1) {

155         /* load the module, if this fails, we're doomed, and we should not try

156          * to load a different variant. */

157         status = load(id, path, module);//load相应库。并把它们的HMI保存到module中。//具体见西分析

158     }

159

  return status;

161 }

 

代码@/hardware/libhardware/hardware.c

这个代码其实很简单。load相应库。并把它们的HMI保存到module中

0 static int load(const char *id,

 61         const char *path,

 62         const struct hw_module_t **pHmi)

 63 {

 64     int status;

 65     void *handle;

 66     struct hw_module_t *hmi;

   handle = dlopen(path, RTLD_NOW);//打开相应的库

 74     if (handle == NULL) {

 75         char const *err_str = dlerror();

 76         LOGE("load: module=%s\n%s", path, err_str?err_str:"unknown");

 77         status = -EINVAL;

 78         goto done;

 79     }

 

 82     const char *sym = HAL_MODULE_INFO_SYM_AS_STR;

 83     hmi = (struct hw_module_t *)dlsym(handle, sym);//找到库中的HMI函数的地址(据snownight0102说,HMI不是一个函数,我还不是很清楚,等待解释)

 84     if (hmi == NULL) {

 85         LOGE("load: couldn't find symbol %s", sym);

 86         status = -EINVAL;

 87         goto done;

 88     }

 89

 90     /* Check that the id matches */

 91     if (strcmp(id, hmi->id) != 0) {//只是一个check

 92         LOGE("load: id=%s != hmi->id=%s", id, hmi->id);

 93         status = -EINVAL;

 94         goto done;

 95     }

 96

 97     hmi->dso = handle;

 98

 99     /* success */

100     status = 0;

    done:

103     if (status != 0) {

104         hmi = NULL;

105         if (handle != NULL) {

106             dlclose(handle);

107             handle = NULL;

108         }

109     } else {

110         LOGV("loaded HAL id=%s path=%s hmi=%p handle=%p",

111                 id, path, *pHmi, handle);

112     }

113

114     *pHmi = hmi;//把这个返回过去

115

116     return status;

117 }

<think>好的,我现在需要解决的问题是用户询问的两个`hw_get_module`函数调用的区别。这两个调用分别是: 1. `hw_get_module("chao_hal", (hw_module_t const **)&module);` 2. `hw_get_module(HARDWARE_MODULE_ID, &hw_module);` 首先,我需要回忆一下Android HAL(硬件抽象层)的相关知识。`hw_get_module`是Android系统中用于加载硬件模块的函数,属于HAL层的一部分。它的作用是根据给定的模块ID查找并加载对应的共享库,然后返回对应的模块结构体。 接下来,我需要分析这两个调用的不同之处。首先看参数部分。第一个参数是模块ID,第二个参数是用于接收模块指针的指针。 第一个调用中的模块ID是字符串"chao_hal",而第二个调用使用的是宏定义`HARDWARE_MODULE_ID`。通常,`HARDWARE_MODULE_ID`是一个预定义的宏,比如在某个硬件模块的头文件中定义的,比如`#define HARDWARE_MODULE_ID "audio"`或者其他具体的模块名称。所以这里的不同可能在于模块ID的不同,一个是特定的"chao_hal",另一个是标准模块ID。 然后是第二个参数的类型转换问题。在第一个调用中,用户显式地将`module`的地址转换为`hw_module_t const **`类型,而第二个调用直接传递了`&hw_module`,这里假设`hw_module`的类型是`hw_module_t*`,所以`&hw_module`的类型应该是`hw_module_t**`,而函数期望的是`const hw_module_t**`类型。这时候可能需要考虑类型转换是否必要,或者是否有潜在的类型不匹配问题。 接下来,我需要考虑这两个调用在功能上的区别。使用不同的模块ID会导致加载不同的硬件模块。例如,如果"chao_hal"是一个自定义或第三方开发的HAL模块,而`HARDWARE_MODULE_ID`是系统标准定义的模块ID(如gralloc、audio等),那么这两个调用分别加载了不同的模块。 另外,类型转换的问题可能需要进一步分析。在C语言中,如果`module`变量的类型是`hw_module_t*`,那么`&module`的类型就是`hw_module_t**`。而函数`hw_get_module`的第二个参数类型应该是`const hw_module_t**`,所以在第一个调用中需要进行强制类型转换,将`hw_module_t**`转换为`const hw_module_t**`。而第二个调用中,如果`hw_module`的类型是`hw_module_t*`,那么`&hw_module`的类型是`hw_module_t**`,同样需要转换为`const hw_module_t**`。但用户提供的第二个调用没有显式转换,可能是因为在上下文中`hw_module`已经声明为`const hw_module_t*`类型,或者编译器能够隐式转换,或者可能存在某种警告或错误。 总结起来,这两个调用的主要区别在于加载的模块ID不同,以及可能的类型转换处理。模块ID的不同导致加载不同的硬件模块,而类型转换可能涉及代码规范或编译器严格性的问题。 可能还需要查阅Android的官方文档或源码来确认`hw_get_module`的具体参数类型和用法。例如,在Android源码中,`hw_get_module`的原型通常是: ```c int hw_get_module(const char *id, const struct hw_module_t **module); ``` 因此,第二个参数需要是指向`const hw_module_t*`的指针。如果调用者的变量不是const的,就需要进行强制类型转换。例如,第一个调用中的`&module`如果原本是`hw_module_t**`类型,就需要转换为`const hw_module_t**`,而第二个调用中的`&hw_module`如果其类型是`const hw_module_t**`则不需要转换,否则可能需要转换。 因此,用户的两个调用可能在模块ID的选择和const正确性处理上存在差异,导致不同的加载结果和潜在的编译器警告或错误。</think>这两个调用在功能及参数处理上有以下区别: --- ### **1. 模块ID差异** - **`"chao_hal"`** 明确指定加载一个名为 `"chao_hal"` 的自定义或第三方硬件模块。这通常是开发者自行实现的 HAL(硬件抽象层)模块,用于特定硬件或功能的扩展。 - **`HARDWARE_MODULE_ID`** 使用预定义的宏,代表系统标准模块ID(如 `"gralloc"`、`"audio"` 等)。该宏在对应模块的头文件中定义,指向 Android 官方支持的硬件模块。 --- ### **2. 参数类型差异** - **第一个调用** `(hw_module_t const **)&module` 包含显式的类型转换,目的是将 `module` 的指针强制转换为 `const hw_module_t**` 类型。 **原因**:`hw_get_module` 的第二个参数类型是 `const hw_module_t**`,若调用者定义的 `module` 是非 `const` 的(如 `hw_module_t* module;`),则需要强制转换以避免编译器警告。 - **第二个调用** `&hw_module` 未显式转换,可能因为 `hw_module` 已定义为 `const hw_module_t*` 类型,或编译器隐式处理了类型兼容性。若未正确定义,可能引发编译警告。 --- ### **3. 用途差异** - **`hw_get_module("chao_hal", ...)`** 用于加载自定义模块,常见于需要扩展非标准硬件功能(如厂商定制传感器、外设驱动等)。 - **`hw_get_module(HARDWARE_MODULE_ID, ...)`** 用于加载 Android 标准硬件模块,例如音频、显示等官方支持的硬件接口。 --- ### **示例代码对比** ```c // 自定义模块加载(需类型转换) hw_module_t *module; // 非 const 类型 hw_get_module("chao_hal", (const hw_module_t**)&module); // 标准模块加载(假设 HARDWARE_MODULE_ID 已定义) const hw_module_t *hw_module; // 正确类型,无需转换 hw_get_module(HARDWARE_MODULE_ID, &hw_module); ``` --- ### **关键总结** | 调用方式 | 模块类型 | 参数处理 | 典型场景 | |-------------------------------------|----------------|------------------------|------------------------| | `hw_get_module("chao_hal", ...)` | 自定义模块 | 需显式类型转换 | 厂商/第三方扩展硬件 | | `hw_get_module(HARDWARE_MODULE_ID, ...)` | 标准模块 | 类型可能隐式兼容 | Android 官方硬件支持 | --- **建议**: 1. 优先使用 `const hw_module_t*` 类型变量,避免强制转换。 2. 自定义模块需确保实现符合 HAL 接口规范(如 `struct hw_module_methods_t`)。 3. 标准模块应查阅对应头文件(如 `hardware/audio.h`)以确认 `HARDWARE_MODULE_ID` 的实际值。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值