1. HAL Stub框架分析
HAL stub的框架比较简单,三个结构体、两个常量、一个函数,简称321架构,它的定义在:
@hardware/libhardware/include/hardware/hardware.h
@hardware/libhardware/hardware.c
-
-
-
- struct hw_module_t{
- uint32_t tag;
- uint16_t version_major;
- uint16_t version_minor;
- const char *id;
- const char *name;
- const char * author;
- struct hw_module_methods_t* methods;
- void* dso;
- uint32_t reserved[32-7];
- };
-
-
-
-
- struct hw_module_methods_t{
-
- int (*open)(const struct hw_module_t* module, const char * id,
- struct hw_device_t** device);
- };
-
-
-
-
- struct hw_device_t{
- uint32_t tag;
- uint32_t version;
- struct hw_module_t* module;
- uint32_t reserved[12];
- int (*close)(struct hw_device_t* device);
- };
上述三个结构之间关系紧密,每个硬件对象由一个hw_module_t来描述,只要我们拿到了这个硬件对象,就可以调用它的open方法,返回这个硬件对象的硬件操作接口,然后就可以通过这些硬件操作接口来间接操作硬件了。只不过,open方法被struct hw_module_methods_t结构封装了一次,硬件操作接口被hw_device_t封装了一次而已。
那用户程序如何才能拿到硬件对象呢?
答案是通过硬件id名来拿。
我们来看下321架构里的:两个符号常量和一个函数:
-
- #define HAL_MODULE_INFO_SYM HMI
-
- #define HAL_MODULE_INFO_SYM_AS_STR "HMI"
-
- int hw_get_module(const char *id, const struct hw_module_t **module);
当用户调用hw_get_module函数时,第一个参数传硬件id名,那么这个函数会从当前系统注册的硬件对象里查找传递过来的id名对应的硬件对象,然后返回之。
从调用者的角度,我们基本上没有什么障碍了,那如何注册一个硬件对象呢?
很简单,只需要声明一个结构体即可,看下面这个Led Stub注册的例子:
- 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 Stub",
- author: "farsight",
- methods: &led_module_methods,
- },
-
- };
对,就这么简单,我们只需要声明一个结构体led_moduel_t,起名叫HAL_MODULE_INFO_SYM,也就是固定的名字:HMI,然后将这个结构体填充好就行了。led_module_t又是什么结构体类型啊?前面分析hw_modult_t类型时说过,我们可以“继承”hw_module_t类型,创建自己的硬件对象,然后自己再扩展特有属性,这里的led_module_t就是“继承”的hw_module_t类型。注意,继承加上了双引号,因为在C语言里没有继承这个概念:
- struct led_module_t {
- struct hw_module_t common;
- };
结构体led_module_t封装了hw_module_t结构体,也就是说led_module_t这个新(子)结构体包含了旧(父)结构体,在新结构体里可以再扩展一些新的成员。结构体本身就具有封装特性,这不就是面向对象的封装和继承吗!为了显得专业点,我们用UML描述一下:
在上面的类图里,把hw_module_methods_t里封装的open函数指针指针写成open方法。
该open方法既:methods,自然也被子结构体给“继承”下来,我们将它初始化为led_module_methods的地址,该结构是hw_module_methods_t类型的,其声明代码如下:
- static struct hw_module_methods_t led_module_methods = {
- open: led_device_open
- };
简洁,我喜欢!!,它里面仅有的open成员是个函数指针,它被指向led_device_open函数:
- static int led_device_open(const struct hw_module_t* module, const char* name,
- struct hw_device_t** device)
- {
- struct led_device_t *led_device;
- LOGI("%s E ", __func__);
- led_device = (struct led_device_t *)malloc(sizeof(*led_device));
- memset(led_device, 0, sizeof(*led_device));
-
-
- led_device->common.tag= HARDWARE_DEVICE_TAG;
- led_device->common.version = 0;
- led_device->common.module= module;
- led_device->common.close = led_device_close;
-
-
- led_device->set_on= led_set_on;
- led_device->set_off= led_set_off;
- led_device->get_led_count = led_getcount;
- *device= (struct hw_device_t *)led_device;
-
- if((fd=open("/dev/leds",O_RDWR))==-1)
- {
- LOGI("open error");
- return -1;
- }else
- LOGI("open ok\n");
-
- return 0;
- }
led_device_open函数的功能:
Ø 分配硬件设备操作结构体led_device_t,该结构体描述硬件操作行为
Ø 初始化led_device_t的父结构体hw_device_t成员
Ø 初始化led_device_t中扩展的操作接口
Ø 打开设备,将led_device_t结构体以父结构体类型返回(面向对象里的多态)
hw_module_t与hw_module_methods_t及硬件open函数的关系如下:
我们来看下led_device_t和其父结构体hw_device_t的关系:
- struct led_device_t {
- struct hw_device_t common;
-
- int (*getcount_led)(struct led_device_t *dev);
- int (*set_on)(struct led_device_t *dev);
- int (*set_off)(struct led_device_t *dev);
- };
用UML类图来表示:
由类图可知,led_device_t扩展了三个接口:seton(), setoff(),get_led_count()。
那么剩下的工作就是实现子结构中新扩展的三个接口了:
- static int led_getcount(struct led_control_device_t*dev)
- {
- LOGI("led_getcount");
- return 4;
- }
-
- static int led_set_on(struct led_control_device_t *dev)
- {
- LOGI("led_set_on");
- ioctl(fd,GPG3DAT2_ON,NULL);
- return 0;
- }
-
- static int led_set_off(struct led_control_device_t*dev)
- {
- LOGI("led_set_off");
- ioctl(fd,GPG3DAT2_OFF,NULL);
- return 0;
- }
这三个接口函数直接和底层驱动打交道去控制硬件,具体驱动部分我们不去讲,那是另外一个体系了。
总结一下:
我们有一个硬件id名,通过这个id调用hw_get_module(char*id, struct hw_module_t **module),这个函数查找注册在当前系统中与id对应的硬件对象并返回之,硬件对象里有个通过hw_module_methods_t结构封装的open函数指针,回调这个open函数,它返回封装有硬件操作接口的led_device_t结构体,这样我们可以通过这个硬件接口去间接的访问硬件了。
在这个过程中hw_get_module返回的是子结构体类型led_module_t,虽然函数的第二个参数类型为hw_module_t的父类型,这里用到了面向对象里的多态的概念。
下面还有一个问题我们没有解决,为什么我们声明了一个名字为HMI结构体后,它就注册到了系统里?hw_get_module函数怎么找到并返回led_module_t描述的硬件对象的?
杀鸡取卵找HAL Stub
如果要知道为什么通过声明结构体就将HALStub注册到系统中,最好的方法是先知道怎么样通过hw_get_module_t来找到注册的硬件对象。
我们分析下hw_get_module函数的实现:
@hardware/libhardware/hardware.c
- static const char *variant_keys[] = {
- “ro.hardware”,
- “ro.product.board”,
- “ro.board.platform”,
- “ro.arch”
- };
-
- struct constint HAL_VARIANT_KEYS_COUNT = (sizeof(variant_keys)/sizeof(variant_keys[0]));
-
- int hw_get_module(const char *id, const struct hw_module_t **module){
-
- return hw_get_module_by_class(id, NULL, module);
- }
-
- int hw_get_module_by_class(const char *class_id, const char *inst,
- const struct hw_module_t **module){
- int status;
- int i;
-
- const struct hw_module_t *hmi = NULL;
- char prop[PATH_MAX};
- char path[PATH_MAX];
- char name[PATH_MAX];
-
- if(inst)
- snprintf(name, PATH_MAX, “%s.%s”, class_id, inst);
- else
- strlcpy(name, class_id, PATH_MAX);
-
- for(i=0; i<HAL_VARIANT_KEYS_COUNT+1; i++){
- if(i<HAL_VARIANT_KEYS_COUNT){
-
- if(property_get(variant_keys[i], prop, NULL) == 0){
- continue;
- }
-
- snprintf(path, sizeof(path), “%s/%s.%s.so”,
- HAL_LIBRARY_PATH2, name, prop);
- if(access(path, R_OK) ==0) break;
-
- snprintf(path, sizeof(path), “%s/%s.%s.so”,
- HAL_LIBRARY_PATH1, name, prop);
- If(access(path, R_OK) == 0) break;
- } else {
-
- snprintf(path, sizeof(path), “%s/%s.default.so”,
- HAL_LIBRARY_PATH1, name);
- If(access(path, R_OK) == 0) break;
- }
- }
- status = -ENOENT;
- if(i<HAL_VARIANT_KEYS_COUNT+1){
- status = load(class_id, path, module);
- }
- return status;
- }
-
- static int load(const char *id, counst char *path, const struct hw_module_t **pHmi){
- void *handle;
- struct hw_module_t * hmi;
-
- handle = dlopen(path, RTLD_NOW);
-
- const char * sym = HAL_MODULE_INFO_SYM_AS_STR;
-
- hmi = (struct hw_module_t *)dlsym(handle, sym);
-
-
- if(strcmp(id, hmi->) != 0){
-
- }
-
- hmi->dso = handle;
-
- *pHmi = hmi;
-
- }
通过上面代码的注释分析可知,硬件对象声明的结构体代码被编译成了so库,由于该结构体声明为const类型,被so库包含在其静态代码段里,要找到硬件对象,首先要找到其对应的so库,再通过dlopen,dlsym这种“杀鸡取卵”的方式找到硬件对象,当然这儿的:“鸡”是指:so库,“卵”既:硬件对象led_module_t结构。
在声明结构体led_module_t时,其名字统一定义为了HMI,而这么做的目的就是为了通过dlsym来查找led HAL Stub源码生成的so库里的”HMI”符号。现在很明显了,我们写的HAL Stub代码最终要编译so库文件,并且库文件名为:led.default.so(当然可以设置四个系统属性之一来指定名字为:led.属性值.so),并且库的所在目录为:/system/lib/hw/。
现在底层的实现部分基本上吃透了,现在我们把目光放到调用者上,根据本章开头介绍可知,上层调用本地代码要使用JNI技术,我们先来恶补下JNI的知识吧。