Android--hw_get_module解析

最新推荐文章于 2022-08-03 10:00:38 发布

Tinghua_M

最新推荐文章于 2022-08-03 10:00:38 发布

阅读量1.3w

点赞数 5

分类专栏： Android 文章标签： android hal

本文链接：https://blog.csdn.net/mdx20072419/article/details/10354651

版权

Android 专栏收录该内容

47 篇文章 2 订阅

订阅专栏

我们知道，google为了保护硬件厂商的信息，在Android中添加了一层，也就是大名鼎鼎的HAL层。

在看HAL的编写方法的过程中，会发现整个模块貌似没有一个入口。一般说来模块都要有个入口，比

如应用程序有main函数，可以为加载器进行加载执行，dll文件有dllmain，而对于我们自己写的动态

链接库，我们可以对库中导出的任何符号进行调用。
问题来了，Android中的HAL是比较具有通用性的，需要上层的函数对其进行加载调用，Android的

HAL加载器是如何实现对不同的Hardware Module进行通用性的调用的呢？
带着这个疑问查看Android源码，会发现Android中实现调用HAL是通过hw_get_module实现的。

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

这是其函数原型，id会指定Hardware的id，这是一个字符串，比如我们比较熟悉的led的id是
#define SENSORS_HARDWARE_MODULE_ID “led”，如果找到了对应的hw_module_t结构体，

会将其指针放入*module中。看看它的实现。

124 int hw_get_module(const char *id, const struct hw_module_t **module)
125 {
126     int status;
127     int i;                                                                                      
128     const struct hw_module_t *hmi = NULL;
129     char prop[PATH_MAX];
130     char path[PATH_MAX];
131 
132     /*
133      * Here we rely on the fact that calling dlopen multiple times on
134      * the same .so will simply increment a refcount (and not load
135      * a new copy of the library).
136      * We also assume that dlopen() is thread-safe.
137      */
138 
139     /* Loop through the configuration variants looking for a module */
140     for (i=0 ; i<HAL_VARIANT_KEYS_COUNT+1 ; i++) {
141         if (i < HAL_VARIANT_KEYS_COUNT) {
142             if (property_get(variant_keys[i], prop, NULL) == 0) { //获取数组variant_keys里的属性值

143                 continue;
144             }
145             snprintf(path, sizeof(path), "%s/%s.%s.so",
146                     HAL_LIBRARY_PATH, id, prop);//如果开发板叫做fs100，这里就加载system/lib/hw/led.fs100.so
147         } else {  snprintf(path, sizeof(path), "%s/%s.default.so",
149                     HAL_LIBRARY_PATH, id);//这里默认加载system/lib/hw/led.default.so
150         }
151         if (access(path, R_OK)) {
152             continue;
153         }
154         /* we found a library matching this id/variant */
155         break;
156     }
157 
158     status = -ENOENT;
159     if (i < HAL_VARIANT_KEYS_COUNT+1) {
160         /* load the module, if this fails, we're doomed, and we should not try
161          * to load a different variant. */
162         status = load(id, path, module);//load函数是关键，调用load函数打开动态链接库
163     }
164 
165     return status;
166 }

上述代码主要是获取动态链接库的路径，并调用load函数去打开指定路径下的库文件，load函数是关键所在。

好，那我们就来解开load函数的神秘面纱！！！

 65 static int load(const char *id,
 66         const char *path,
 67         const struct hw_module_t **pHmi)
 68 {
 69     int status;
 70     void *handle;
 71     struct hw_module_t *hmi;
 72 
 73     /*
 74      * load the symbols resolving undefined symbols before
 75      * dlopen returns. Since RTLD_GLOBAL is not or'd in with
 76      * RTLD_NOW the external symbols will not be global
 77      */
 78     handle = dlopen(path, RTLD_NOW);
 79     if (handle == NULL) {
 80         char const *err_str = dlerror();
 81         LOGE("load: module=%s\n%s", path, err_str?err_str:"unknown");
 82         status = -EINVAL;
 83         goto done;
 84     }
 85 
 86     /* Get the address of the struct hal_module_info. */
 87     const char *sym = HAL_MODULE_INFO_SYM_AS_STR;
 88     hmi = (struct hw_module_t *)dlsym(handle, sym);
 89     if (hmi == NULL) {
 90         LOGE("load: couldn't find symbol %s", sym);
 91         status = -EINVAL;
 92         goto done;
 93     }
 94 
 95     /* Check that the id matches */
 96     if (strcmp(id, hmi->id) != 0) {
 97         LOGE("load: id=%s != hmi->id=%s", id, hmi->id);
 98         status = -EINVAL;
 99         goto done;
100     }
101 
102     hmi->dso = handle;
103 
104     /* success */
105     status = 0;
106 
 93     }
 94 
 95     /* Check that the id matches */
 96     if (strcmp(id, hmi->id) != 0) {
 97         LOGE("load: id=%s != hmi->id=%s", id, hmi->id);
 98         status = -EINVAL;
 99         goto done;
100     }
101 
102     hmi->dso = handle;
103 
104     /* success */
105     status = 0;
106 
107     done:
108     if (status != 0) {
109         hmi = NULL;
110         if (handle != NULL) {
111             dlclose(handle);
112             handle = NULL;
113         }
114     } else {
115         LOGV("loaded HAL id=%s path=%s hmi=%p handle=%p",
116                 id, path, *pHmi, handle);
117     }
118 
119     *pHmi = hmi;
120 
121     return status;
122 }

这里有一个宏HAL_MODULE_INFO_SYM_AS_STR需要注意：

#define HAL_MODULE_INFO_SYM_AS_STR  "HMI"

其中 hmi = (struct hw_module_t *)dlsym(handle, sym);

这里是查找“HMI”这个导出符号，并获取其地址。

看到这里，我们不禁要问，为什么根据“HMI”这个导出符号，就可以从动态链接库中找到结构体hw_module_t呢？？

我们知道，ELF = Executable and Linkable Format，可执行连接格式，是UNIX系统实验室（USL）作为应用程序二进制接口（Application Binary Interface，ABI）而开发和发布的，扩展名为elf。一个ELF头在文件的开始，保存了路线图(road map)，描述了该文件的组织情况。sections保存着object 文件的信息，从连接角度看：包括指令，数据,符号表，重定位信息等等。我们的led.default.so就是一个elf格式的文件。

linux@ubuntu:~/eclair_2.1_farsight/out/target/product/fs100/system/lib/hw$ file led.default.so 
led.default.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, stripped

所以说，我们可以使用unix给我们提供的readelf命令去查看相应的符号信息，就一目了然了！

linux@ubuntu:~/eclair_2.1_farsight/out/target/product/fs100/system/lib/hw$ readelf -s led.default.so 

Symbol table '.dynsym' contains 25 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 000004c8     0 SECTION LOCAL  DEFAULT    7 
     2: 00001000     0 SECTION LOCAL  DEFAULT   11 
     3: 00000000     0 FUNC    GLOBAL DEFAULT  UND ioctl
     4: 000006d4     0 NOTYPE  GLOBAL DEFAULT  ABS __exidx_end
     5: 00000000     0 FUNC    GLOBAL DEFAULT  UND __aeabi_unwind_cpp_pr0
     6: 00001178     0 NOTYPE  GLOBAL DEFAULT  ABS _bss_end__
     7: 00000000     0 FUNC    GLOBAL DEFAULT  UND malloc
     8: 00001174     0 NOTYPE  GLOBAL DEFAULT  ABS __bss_start__
     9: 00000000     0 FUNC    GLOBAL DEFAULT  UND __android_log_print
    10: 000006ab     0 NOTYPE  GLOBAL DEFAULT  ABS __exidx_start
    11: 00001174     4 OBJECT  GLOBAL DEFAULT   15 fd
    12: 000005d5    60 FUNC    GLOBAL DEFAULT    7 led_set_off
    13: 00001178     0 NOTYPE  GLOBAL DEFAULT  ABS __bss_end__
    14: 00001174     0 NOTYPE  GLOBAL DEFAULT  ABS __bss_start
    15: 00000000     0 FUNC    GLOBAL DEFAULT  UND memset
    16: 00001178     0 NOTYPE  GLOBAL DEFAULT  ABS __end__
    17: 00001174     0 NOTYPE  GLOBAL DEFAULT  ABS _edata
    18: 00001178     0 NOTYPE  GLOBAL DEFAULT  ABS _end
    19: 00000000     0 FUNC    GLOBAL DEFAULT  UND open
    20: 00080000     0 NOTYPE  GLOBAL DEFAULT  ABS _stack
    21: 00001000   128 OBJECT  GLOBAL DEFAULT   11 HMI
    22: 00001170     0 NOTYPE  GLOBAL DEFAULT   14 __data_start
    23: 00000000     0 FUNC    GLOBAL DEFAULT  UND close
    24: 00000000     0 FUNC    GLOBAL DEFAULT  UND free

在21行我们发现，名字就是“HMI”，对应于hw_module_t结构体。再去对照一下HAL的代码。

const struct led_module_t HAL_MODULE_INFO_SYM = {
    common: {
        tag: HARDWARE_MODULE_TAG,
	    version_major: 1,
	    version_minor: 0,
	    id: LED_HARDWARE_MODULE_ID, 
	    name: "led HAL module",
	    author: "farsight",             
	    methods: &led_module_methods, 
	}, 
	
};

这里定义了一个名为HAL_MODULE_INFO_SYM的copybit_module_t的结构体，common成员为hw_module_t类型。注意这里的HAL_MODULE_INFO_SYM变量必须为这个名字，这样编译器才会将这个结构体的导出符号变为“HMI”，这样这个结构体才能被dlsym函数找到！

综上，我们知道了andriod HAL模块也有一个通用的入口地址，这个入口地址就是HAL_MODULE_INFO_SYM变量，通过它，我们可以访问到HAL模块中的所有想要外部访问到的方法。

Tinghua_M

关注

5
点赞
踩
40

收藏

觉得还不错? 一键收藏
1
评论
Android--hw_get_module解析

我们知道，google为了保护硬件厂商的信息，在Android中添加了一层，也就是大名鼎鼎的HAL层。在看HAL的编写方法的过程中，会发现整个模块貌似没有一个入口。一般说来模块都要有个入口，比如应用程序有main函数，可以为加载器进行加载执行，dll文件有dllmain，而对于我们自己写的动态链接库，我们可以对库中导出的任何符号进行调用。问题来了，Android中的HAL是
复制链接

扫一扫