android HAL接口的編碼小結

定義一個modulestruct 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.