android HAL接口的编码小结

定义一个module

struct xxx_module_t  {

     hw_module_t common;

     xxx，这里的主要是一些在未open时就可以操作该模块的ops接口，有时候可以不填充

}

struct xxx_mdoule HAL_MODULE_INFO_SYM =

{

     填充该结构体，以填充hw_module_t为主

}//所有的hal模块的名字都一样，该结构在编译时会转为一个hmi的描述符，供load对应的so时的使用。同时load的id要与hw_module_t相一致。

其中hw_module_t 的methods一般需要指定并实现一个open的接口，如下所示：

typedef struct hw_module_methods_t {

    /** Open a specific device */
    int (*open)(const struct hw_module_t* module, const char* id,

            struct hw_device_t** device);

} hw_module_methods_t;

一般在open后需要返回一个模块需要用到的设备xxx_device_t接口，一般结构如下,需要注意的是多重封装时，也需要确保hw_device_t 位于返回首地址即可：

typedef struct xxx_device_t {

     hw_device_t common;

     xxx各种可操作device的ops函数。

     

}

或则

class xxx_xxxx_t: public struct xxx_device_t{

     xxx_xxx_t();

}

在构造函数中xxx_xxxx_t()

{

     完成对xxx_device_t 的初始化包括common和各种framework层需要的ops

}

hw_device_t的结构体定义：

typedef 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_device_t;

综上所述，HAL是通过struct xxx_device_t这个结构体向上层提供接口的.

即：接口包含在struct xxx_device_t这个结构体内。

而具体执行是通过struct xxx_module_t HAL_MODULE_INFO_SYM这个结构体变量的函数列表成员下的open函数来返回给上层的.

附加：

之所以将HAL所有的模块命名为HAL_MODULE_INFO_SYM原因在于该名字会被替换为一个宏名HMI，即最终编译器对每一个模块的CPP进行组合生产so库时，内部是由一个HMI的符号表存在的。而这个符号表再load module时会首先进行dlsym的操作，其中明确规定要查找的符号入口为“HMI”，这就要求当前模块必须含有这个符号名。也就要求每一个HAL库要确保自己的名字是HAL_MODULE_INFO_SYM因为只有这个名字才会被替换为HMI后编译进入SO文件中，从而被load出HMI的入口即hw_module_t.