HAL Stub框架

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

@hardware/libhardware/hardware.c

1. /*  

2. 每一个硬件都通过hw_module_t来描述，我们称之为一个硬件对象。你可以去“继承”这个hw_module_t，然后扩展自己的属性，硬件对象必须定义为一个固定的名字：HMI，即：Hardware Module Information的简写，每一个硬件对象里都封装了一个函数指针open用于打开该硬件，我们理解为硬件对象的open方法，open调用后返回这个硬件对应的Operation interface。 

3. */  

4.  struct hw_module_t｛  

5.     uint32_t tag;           // 该值必须声明为HARDWARE_MODULE_TAG  

6.     uint16_t version_major; // 主版本号  

7.     uint16_t version_minor;     // 次版本号  

8.     const char *id;         //硬件id名，唯一标识module  

9.     const char *name;       // 硬件module名字  

10.     const char * author;        // 作者  

11.     struct hw_module_methods_t* methods;    //指向封装有open函数指针的结构体  

12.     void* dso;              // module’s dso  

13.     uint32_t reserved[32-7];    // 128字节补齐  

14. ｝;  

15.   

16./*  

17.硬件对象的open方法描述结构体，它里面只有一个元素：open函数指针 

18.*/  

19. struct hw_module_methods_t{  

20.     // 只封装了open函数指针  

21.     int (*open)(const struct hw_module_t* module, const char * id,  

22.         struct hw_device_t** device);  

23. };  

24.   

25./* 

26.硬件对象hw_module_t的open方法返回该硬件的Operation interface，它由hw_device_t结构体来描述，我们称之为：该硬件的操作接口 

27.*/  

28. struct hw_device_t{  

29.     uint32_t tag;               // 必须赋值为HARDWARE_DEVICE_TAG  

30.     uint32_t version;               // 版本号  

31.     struct hw_module_t* module; // 该设备操作属于哪个硬件对象，可以看成硬件操作接口与硬件对象的联系  

32.     uint32_t reserved[12];          // 字节补齐  

33.     int (*close)(struct hw_device_t* device);   // 该设备的关闭函数指针，可以看做硬件的close方法  

34. };  

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

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

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

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

1. // 这个就是HAL Stub对象固定的名字  

2. #define HAL_MODULE_INFO_SYM             HMI  

3. // 这是字符串形式的名字  

4. #define HAL_MODULE_INFO_SYM_AS_STR      "HMI"  

5. //这个函数是通过硬件名来获得硬件HAL Stub对象  

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

当用户调用hw_get_module函数时，第一个参数传硬件id名，那么这个函数会从当前系统注册的硬件对象里查找传递过来的id名对应的硬件对象，然后返回之。

从调用者的角度，我们基本上没有什么障碍了，那如何注册一个硬件对象呢？

很简单，只需要声明一个结构体即可，看下面这个Led Stub注册的例子：

1. const struct led_module_t HAL_MODULE_INFO_SYM = {  

2.     common: {   // 初始化父结构hw_module_t成员  

3.         tag: HARDWARE_MODULE_TAG,  

4.         version_major: 1,  

5.         version_minor: 0,  

6.         id: LED_HARDWARE_MODULE_ID,  

7.         name: "led HAL Stub",  

8.         author: "farsight",  

9.         methods: &led_module_methods,  

10.     },   

11.     // 扩展属性放在这儿  

12. };  

对，就这么简单，我们只需要声明一个结构体led_moduel_t，起名叫HAL_MODULE_INFO_SYM，也就是固定的名字：HMI，然后将这个结构体填充好就行了。led_module_t又是什么结构体类型啊？前面分析hw_modult_t类型时说过，我们可以“继承”hw_module_t类型，创建自己的硬件对象，然后自己再扩展特有属性，这里的led_module_t就是“继承”的hw_module_t类型。注意，继承加上了双引号，因为在C语言里没有继承这个概念：

1. struct led_module_t {  

2.     struct hw_module_t common;  

3. };  

结构体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类型的，其声明代码如下：

1. static struct hw_module_methods_t led_module_methods = {  

2.     open: led_device_open    

3. };  

它里面仅有的open成员是个函数指针，它被指向led_device_open函数:

1. static int led_device_open(const struct hw_module_t* module, const char* name,  

2.     struct hw_device_t** device)  

3. {  

4.     struct led_device_t *led_device;  

5.     LOGI("%s E ", __func__);  

6.     led_device = (struct led_device_t *)malloc(sizeof(*led_device));  

7.     memset(led_device, 0, sizeof(*led_device));   

8.   

9.     // init hw_device_t  

10.     led_device->common.tag= HARDWARE_DEVICE_TAG;  

11.     led_device->common.version = 0;  

12.     led_device->common.module= module;  

13.     led_device->common.close = led_device_close;   

14.   

15.     // init operation interface  

16.     led_device->set_on= led_set_on;  

17.     led_device->set_off= led_set_off;  

18.     led_device->get_led_count = led_getcount;  

19.     *device= (struct hw_device_t *)led_device;  

20.   

21.     if((fd=open("/dev/leds",O_RDWR))==-1)  

22.     {  

23.         LOGI("open error");  

24.         return -1;  

25.     }else  

26.     LOGI("open ok\n");  

27.   

28.     return 0;  

29. }  

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的关系：

1. struct led_device_t {  

2.     struct hw_device_t common;   // led_devict_t的父结构，它里面只封装了close方法  

3.     // 下面三个函数指针是子结构led_device_t对父结构hw_device_t的扩展，可以理解为子类扩展了父类增加了三个方法  

4.     int (*getcount_led)(struct led_device_t *dev);  

5.     int (*set_on)(struct led_device_t *dev);  

6.     int (*set_off)(struct led_device_t *dev);  

7. };  

用UML类图来表示：

由类图可知，led_device_t扩展了三个接口：seton()， setoff()，get_led_count()。

那么剩下的工作就是实现子结构中新扩展的三个接口了：

1. static int led_getcount(struct led_control_device_t*dev)  {  

2.          LOGI("led_getcount");  

3.          return 4;  

4. }  

5.    

6.  static int led_set_on(struct led_control_device_t *dev)  {     

7.          LOGI("led_set_on");  

8.          ioctl(fd,GPG3DAT2_ON,NULL);  

9.          return 0;  

10. }  

11.    

12. static int led_set_off(struct led_control_device_t*dev)  {  

13.          LOGI("led_set_off");  

14.          ioctl(fd,GPG3DAT2_OFF,NULL);  

15.          return 0;  

16. }  

这三个接口函数直接和底层驱动打交道去控制硬件，具体驱动部分我们不去讲，那是另外一个体系了。

总结一下：

        我们有一个硬件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的父类型，这里用到了面向对象里的多态的概念。