深入浅出 - Android系统移植与平台开发（八）－ HAL Stub框架分析

骑猪看日落 2022-05-22 08:35 130阅读 0赞

## 1.      HAL Stub框架分析 ##

HAL stub的框架比较简单，三个结构体、两个常量、一个函数，简称321架构，它的定义在：

@hardware/libhardware/include/hardware/hardware.h

@hardware/libhardware/hardware.c

/* 
    每一个硬件都通过hw_module_t来描述，我们称之为一个硬件对象。你可以去“继承”这个hw_module_t，然后扩展自己的属性，硬件对象必须定义为一个固定的名字：HMI，即：Hardware Module Information的简写，每一个硬件对象里都封装了一个函数指针open用于打开该硬件，我们理解为硬件对象的open方法，open调用后返回这个硬件对应的Operation interface。
    */
    struct hw_module_t｛
    	uint32_t tag;			// 该值必须声明为HARDWARE_MODULE_TAG
    	uint16_t version_major;	// 主版本号
    	uint16_t version_minor; 	// 次版本号
    	const char *id;			//硬件id名，唯一标识module
    	const char *name;		// 硬件module名字
    	const char * author;		// 作者
    	struct hw_module_methods_t* methods;	//指向封装有open函数指针的结构体
    	void* dso;				// module’s dso
    	uint32_t reserved[32-7];	// 128字节补齐
    ｝;
    
    /* 
    硬件对象的open方法描述结构体，它里面只有一个元素：open函数指针
    */
    struct hw_module_methods_t{
    	// 只封装了open函数指针
    	int (*open)(const struct hw_module_t* module, const char * id,
    		struct hw_device_t** device);
    };
    
    /*
    硬件对象hw_module_t的open方法返回该硬件的Operation interface，它由hw_device_t结构体来描述，我们称之为：该硬件的操作接口
    */
    struct hw_device_t{
    	uint32_t tag;				// 必须赋值为HARDWARE_DEVICE_TAG
    	uint32_t version;				// 版本号
    	struct hw_module_t* module;	// 该设备操作属于哪个硬件对象，可以看成硬件操作接口与硬件对象的联系
    	uint32_t reserved[12];			// 字节补齐
    	int (*close)(struct hw_device_t* device);	// 该设备的关闭函数指针，可以看做硬件的close方法
    };

上述三个结构之间关系紧密，每个硬件对象由一个hw\_module\_t来描述，只要我们拿到了这个硬件对象，就可以调用它的open方法，返回这个硬件对象的硬件操作接口，然后就可以通过这些硬件操作接口来间接操作硬件了。只不过，open方法被struct hw\_module\_methods\_t结构封装了一次，硬件操作接口被hw\_device\_t封装了一次而已。

那用户程序如何才能拿到硬件对象呢？

答案是通过硬件id名来拿。

我们来看下321架构里的：两个符号常量和一个函数：

// 这个就是HAL Stub对象固定的名字
    #define HAL_MODULE_INFO_SYM         	HMI
    // 这是字符串形式的名字
    #define HAL_MODULE_INFO_SYM_AS_STR  	"HMI"
    //这个函数是通过硬件名来获得硬件HAL Stub对象
    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: {	// 初始化父结构hw_module_t成员
            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描述一下：  
![1350303425_6103.png][]

在上面的类图里，把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)); 
    
    	// init hw_device_t
    	led_device->common.tag= HARDWARE_DEVICE_TAG;
    	led_device->common.version = 0;
    	led_device->common.module= module;
    	led_device->common.close = led_device_close; 
    
    	// init operation interface
    	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函数的关系如下：

![1350303529_8582.png][]  
我们来看下led\_device\_t和其父结构体hw\_device\_t的关系：

struct led_device_t {
    	struct hw_device_t common;   // led_devict_t的父结构，它里面只封装了close方法
    	// 下面三个函数指针是子结构led_device_t对父结构hw_device_t的扩展，可以理解为子类扩展了父类增加了三个方法
    	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类图来表示：  
![1350303589_5293.png][]

由类图可知，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”
    };
    // 由上面定义的字符串数组可知，HAL_VARIANT_KEYS_COUNT的值为4
    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){
    	// 调用3个参数的hw_get_module_by_class函数
    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;
    	// 声明一个hw_module_t指针变量hmi
    	const struct hw_module_t *hmi = NULL;
    	char prop[PATH_MAX};
    	char path[PATH_MAX];
    	char name[PATH_MAX];
    	// 由前面调用函数可知，inst ＝ NULL，执行else部分，将硬件id名拷贝到name数组里
    	if(inst)
    		snprintf(name, PATH_MAX, “%s.%s”, class_id, inst);
    	else
    		strlcpy(name, class_id, PATH_MAX);
    	// i 循环5次
    	for(i=0; i<HAL_VARIANT_KEYS_COUNT+1; i++){
    		if(i<HAL_VARIANT_KEYS_COUNT){
    			// 从系统属性里依次查找前面定义的4个属性的值，找其中一个后，执行后面代码，找不到，进入else部分执行
    			if(property_get(variant_keys[i], prop, NULL) == 0){
    				continue;
    			}
    			// 找到一个属性值prop后，拼写path的值为：/vendor/lib/hw/硬件id名.prop.so
    			snprintf(path, sizeof(path), “%s/%s.%s.so”,
    				HAL_LIBRARY_PATH2, name, prop);
    			if(access(path, R_OK) ==0) break;	// 如果path指向有效的库文件，退出for循环
    			// 如果vendor/lib/hw目录下没有库文件，查找/system/lib/hw目录下有没有：硬件id名.prop.so的库文件
    			snprintf(path, sizeof(path), “%s/%s.%s.so”,
    				HAL_LIBRARY_PATH1, name, prop);
    			If(access(path, R_OK) == 0) break;
    		} else {
    			// 如果4个系统属性都没有定义，则使用默认的库名：/system/lib/hw/硬件id名.default.so
    			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);	// 难道是要加载前面查找到的so库？？
    	}
    	return status;
    }
    
    static int load(const char *id, counst char *path, const struct hw_module_t **pHmi){
    	void *handle;
    	struct hw_module_t * hmi;
    	// 通过dlopen打开so库
    	handle = dlopen(path, RTLD_NOW);
    	// sym的值为”HMI”，这个名字还有印象吗？
    	const char * sym = HAL_MODULE_INFO_SYM_AS_STR;
    	// 通过dlsym从打开的库里查找”HMI”这个符号，如果在so代码里有定义的函数名或变量名为HMI，dlsym返回其地址hmi，将该地址转化成hw_module_t类型，即，硬件对象，这招够狠，“杀鸡取卵”
    	hmi = (struct hw_module_t *)dlsym(handle, sym);	
    	// 判断找到的硬件对象的id是否和要查找的id名一致，不一致出错退出
    // 取了卵还要验证下是不是自己要的“卵”
    	if(strcmp(id, hmi->) != 0){
    		// 出错退出处理
    	}
    	// 将库的句柄保存到hmi硬件对象的dso成员里
    	hmi->dso = handle;
    	// 将硬件对象地址送给load函数者，最终将硬件对象返回到了hw_get_module的调用者
    	*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的知识吧。

[1350303425_6103.png]: https://img-my.csdn.net/uploads/201210/15/1350303425_6103.png
[1350303529_8582.png]: https://img-my.csdn.net/uploads/201210/15/1350303529_8582.png
[1350303589_5293.png]: https://img-my.csdn.net/uploads/201210/15/1350303589_5293.png