某天，某大佬突然丢给我一本李忠良编著的Android源码分析实录，内容确实晦涩难懂。特，有此一记。
什么是HAL层
如名所示，HAL的主要功能是将硬件抽象化。它位于操作系统内核和硬件电路之间的接口层。HAL层隐藏了特定平台硬件接口细节，为操作系统提供虚拟硬件平台，使其具有硬件无关性。这样就可以使操作系统在多种平台上进行移植。
硬件支持的实现
Android系统对硬件的支持划分为两层来实现，原因如下:
1. Linux内核代码遵守GPL1协议，如果Android系统将对硬件的支持完全实现在Linux内核的硬件驱动模块中，那么必须将硬件驱动模块的源代码公开，这是一些人不愿意的。
2. Android系统遵守Apache License 2协议，可以修改或添加某些源代码又不公开它们。
然而，对硬件的支持是无法完全实现在Android系统的用户空间里，因为只有Linux内核空间对硬件的操作有特权。所以: Android操作系统将硬件的访问划分为内核空间和用户空间两层。
其中，内核空间仍然以硬件驱动模块的形式来支持，不过只提供了硬件的访问通道。用户空间采用，硬件抽象层模块的方式支持(HAL)，封装了硬件实现的具体细节和参数。
HAL 架构 (没细讲区别)
过去，HAL采取的是链接库模块观念来架构
现在，调整为HAL stub观念来架构
从架构图上过去的是直接访问so库的形式，HAL stub是一种代理的概念，将so文件隐藏。Stub以*so形式存在，向HAL提供强大的操作函数（Operations），而Runtime则从HAL获取特定的Stub的函数，然后再回调这些操作函数。
HAL Module架构
HAL硬件抽象层采用HAL Module和HAL Stub结合的形式，HAL Stub不是一个共享库，编译时，上层Android系统只拥有访问HAL Stub的函数指针，并不需要HAL Stub。上层通过HAL Module提供的统一接口获取并操作HAL Stub, *.so文件只会被映射到一个进程,也不存在重复映射和重入问题。
HAL Module的三个主要结构体:
* struct hw_module_t;
* struct hw_module_methods_t;
* struct hw_device_t;
结构体的继承
它们的继承关系:hw_device_t -> hw_module_t -> hw_module_methods_t;
对于不同的hardware的HAL，其所需对应的lib命名规则是id.variant.so，比如gralloc.msm7k.so,其中gralloc代表id，msm7k代表变量，变量的取值范围在文件中variant_keys对应的值。
hw_module_t
/**
* Every hardware module must have a data structure named HAL_MODULE_INFO_SYM
* and the fields of this data structure must begin with hw_module_t
* followed by module specific information.
*/
typedef struct hw_module_t {
/** tag must be initialized to HARDWARE_MODULE_TAG */
uint32_t tag;
/**
* The API version of the implemented module. The module owner is
* responsible for updating the version when a module interface has
* changed.
*
* The derived modules such as gralloc and audio own and manage this field.
* The module user must interpret the version field to decide whether or
* not to inter-operate with the supplied module implementation.
* For example, SurfaceFlinger is responsible for making sure that
* it knows how to manage different versions of the gralloc-module API,
* and AudioFlinger must know how to do the same for audio-module API.
*
* The module API version should include a major and a minor component.
* For example, version 1.0 could be represented as 0x0100. This format
* implies that versions 0x0100-0x01ff are all API-compatible.
*
* In the future, libhardware will expose a hw_get_module_version()
* (or equivalent) function that will take minimum/maximum supported
* versions as arguments and would be able to reject modules with
* versions outside of the supplied range.
*/
uint16_t module_api_version;
#define version_major module_api_version
/**
* version_major/version_minor defines are supplied here for temporary
* source code compatibility. They will be removed in the next version.
* ALL clients must convert to the new version format.
*/
/**
* The API version of the HAL module interface. This is meant to
* version the hw_module_t, hw_module_methods_t, and hw_device_t
* structures and definitions.
*
* The HAL interface owns this field. Module users/implementations
* must NOT rely on this value for version information.
*
* Presently, 0 is the only valid value.
*/
uint16_t hal_api_version;
#define version_minor hal_api_version
/** Identifier of module */
const char *id;
/** Name of this module */
const char *name;
/** Author/owner/implementor of the module */
const char *author;
/** Modules methods */
struct hw_module_methods_t* methods;
/** module's dso */
void* dso;
/** padding to 128 bytes, reserved for future use */
uint32_t reserved[32-7];
} hw_module_t;hw_module_t的5点注意:
1. 结构体定义前注释翻译:每一个硬件模块必须拥有一个名叫HAL_MODULE_INFO_SYM的数据结构体，并且这块数据结构体区域必须是hw_module_t类型，之后区域跟随着其他数据。
2. hw_module_t 的成员变量Tag必须设置成HARDWARE_MODULE_TAG这个32位常量（’H‘<<24|’W’<<16|’M’<<8|’T’），标识这是一个硬件抽象层结构体。
3. hw_module_t的成员变量dso用来保存加载硬件抽象层模块后得到的句柄值，前面提到每一个硬件抽象层模块Stub都对应着一个动态链接库文件(*.so)。加载硬件抽象层的过程就是调用dlopen函数来加载其对应动态链接库文件的过程。在调用dlclose函数卸载这个硬件抽象模块的时候就要用到这个句柄值。因此，需要在加载的过程中将它保存起来。
4. hw_module_t成员变量methods 定义了一个硬件抽象层模块的操作方法列表; hw_module_methods_t.
hw_module_methods_t
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;在结构体hw_module_methods_t中只有一个成员变量，即一个函数指针(指向函数入口地址的指针:函数指针的主要两个作用：调用函数和作为函数的参数)open。
open函数指针是用来打开HAL中的硬件设备。在其行参表中，module指硬件设备所在的模块，id表示要打开的硬件id，device表示输出一个硬件设备。
猜测:: 在open函数指针定义的行参列表中，device行参是结构体指针的指针形式，是为了方便设备的切换 使用 *device++可以自指针列表中切换设备。
hw_device_t
/**
* Every device data structure must begin with hw_device_t
* followed by module specific public methods and attributes.
*/
typedef struct hw_device_t {
/** tag must be initialized to HARDWARE_DEVICE_TAG */
uint32_t tag;
/**
* Version of the module-specific device API. This value is used by
* the derived-module user to manage different device implementations.
*
* The module user is responsible for checking the module_api_version
* and device version fields to ensure that the user is capable of
* communicating with the specific module implementation.
*
* One module can support multiple devices with different versions. This
* can be useful when a device interface changes in an incompatible way
* but it is still necessary to support older implementations at the same
* time. One such example is the Camera 2.0 API.
*
* This field is interpreted by the module user and is ignored by the
* HAL interface itself.
*/
uint32_t version;
/** reference to the module this device belongs to */
struct hw_module_t* module;
/** padding reserved for future use */
uint32_t reserved[12];
/** Close this device */
int (*close)(struct hw_device_t* device);
} hw_device_t;- 在hw_device_t的顶部注释中表明:每一个设备数据结构体(device data structure)必须以这个结构体类型变量开始，之后再是一些特别的公共方法和属性。
- 结构体tag变量，必须设置为HARDWARE_DEVICE_TAG(常量值:’H’<<24|’W’<<16|’D’<<8|T),标识为硬件设备结构体。
- 每一个hw_device_t 拥有一个 close函数指针，指向的是当前硬件的关闭函数。
分析文件hardware.c
在hardware.h中申明了两个函数hw_get_moudle 和 hw_get_moudle_by_class
/**
* Get the module info associated with a module by id.
*
* @return: 0 == success, <0 == error and *module == NULL
*/
int hw_get_module(const char *id, const struct hw_module_t **module);
/**
* Get the module info associated with a module instance by class 'class_id'
* and instance 'inst'.
*
* Some modules types necessitate multiple instances. For example audio supports
* multiple concurrent interfaces and thus 'audio' is the module class
* and 'primary' or 'a2dp' are module interfaces. This implies that the files
* providing these modules would be named audio.primary.<variant>.so and
* audio.a2dp.<variant>.so
*
* @return: 0 == success, <0 == error and *module == NULL
*/
int hw_get_module_by_class(const char *class_id, const char *inst,
const struct hw_module_t **module);hw_get_module函数通过模块的ID寻找硬件模块动态链接库的地址。
int hw_get_module(const char *id, const struct hw_module_t **module)
{
return hw_get_module_by_class(id, NULL, module);
}hw_get_module_by_class 通过类别ID和实例来获取与某一个模块实例相关的硬件信息
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)
//如果一个硬件模块存在多个必须的实现的接口方式，所以需要通过inst来获取
//class_id.inst
snprintf(name, PATH_MAX, "%s.%s", class_id, inst);
else
//一般是这种情况
//class_id
strlcpy(name, class_id, PATH_MAX);
/*
* Here we rely on the fact that calling dlopen multiple times on
* the same .so will simply increment a refcount (and not load
* a new copy of the library).
* We also assume that dlopen() is thread-safe.
*/
/* Loop through the configuration variants looking for a module */
for (i=0 ; i<HAL_VARIANT_KEYS_COUNT+1 ; i++) {
if (i < HAL_VARIANT_KEYS_COUNT) {
//检查当前属性是否被设置了值
//将设置值放入prop
if (property_get(variant_keys[i], prop, NULL) == 0) {
continue;
}
/** Base path of the hal modules */
//#define HAL_LIBRARY_PATH1 "/system/lib/hw"
//#define HAL_LIBRARY_PATH2 "/vendor/lib/hw"
snprintf(path, sizeof(path), "%s/%s.%s.so",
HAL_LIBRARY_PATH2, name, prop);
//access函数检查path文件是否存在
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;
//判断条件为TRUE时: 表明上面的循环提前跳出，则找到了文件
if (i < HAL_VARIANT_KEYS_COUNT+1) {
/* load the module, if this fails, we're doomed, and we should not try
* to load a different variant. */
status = load(class_id, path, module);
}
return status;
}以上是寻找.so 硬件的动态链接库的过程
之后介绍 加载.so 硬件动态链接库的过程
主要函数为 load。
打开相应库并获得hw_module_t结构体
Talk is useless, we see the code.
/**
* Load the file defined by the variant and if successful
* return the dlopen handle and the hmi.
* @return 0 = success, !0 = failure.
*/
static int load(const char *id,
const char *path,
const struct hw_module_t **pHmi)
{
int status;
void *handle;
struct hw_module_t *hmi;
/*
* load the symbols resolving undefined symbols before
* dlopen returns. Since RTLD_GLOBAL is not or'd in with
* RTLD_NOW the external symbols will not be global
*/
//dlopen函数第一个行参是地址，第二个行参是打开mode(打开方式)、
// dlopen(const char* filename, int flag);
//RTLD_NOW ：对于动态链接库中的未定义符号 需要在dlopen返回前，解析出所有未定义符号，如果解析不出来，
//dlopen会返回NULL，错误为：: undefined symbol: xxxx.......
handle = dlopen(path, RTLD_NOW);
if (handle == NULL) {
char const *err_str = dlerror();
ALOGE("load: module=%s\n%s", path, err_str?err_str:"unknown");
status = -EINVAL;
goto done;
}
//step1:dlopen 结束
//执行到这里表明: 获取到handle句柄值
//step2：dlsym 开始 获取动态链接库中函数地址或者变量地址
/* Get the address of the struct hal_module_info. */
/**
* Name of the hal_module_info as a string
*/
//#define HAL_MODULE_INFO_SYM_AS_STR "HMI"
const char *sym = HAL_MODULE_INFO_SYM_AS_STR;
hmi = (struct hw_module_t *)dlsym(handle, sym);
if (hmi == NULL) {
ALOGE("load: couldn't find symbol %s", sym);
status = -EINVAL;
//存在即价值，就要无条件跳转了
goto done;
}
//执行到这里进行检查，获取的HMI信息中的id时候与指定的id相等
/* Check that the id matches */
if (strcmp(id, hmi->id) != 0) {
ALOGE("load: id=%s != hmi->id=%s", id, hmi->id);
status = -EINVAL;
goto done;
}
//将第一步打卡加载获取的句柄赋值给hmi用于关闭dlclose关闭动态链接库时调用
hmi->dso = handle;
//标记成功
/* success */
status = 0;
done:
if (status != 0) {
hmi = NULL;
if (handle != NULL) {
dlclose(handle);
handle = NULL;
}
} else {
ALOGV("loaded HAL id=%s path=%s hmi=%p handle=%p",
id, path, *pHmi, handle);
}
//传指针的形式返回获取的module
*pHmi = hmi;
return status;
}以上是Android的HAL硬件抽象层的硬件动态链接库的加载理论
举例分析 待续。。。