对Android Hal的一些肤浅理解（有大神路过，赐教）

           Android驱动Hal学习总结

 

 

  下面是这段时间研究Android驱动程序框架的心得，要进行深一步的研究还得深入代码分析。

   Android是基于Linux 2.6.x kernel的操作系统。我们知道Linux kernel 的开源协议是GPL。这下问题来了：如果你是硬件厂商，希望你的硬件能在 Linux kernel 下运作，那么就必须要有驱动程序。如果驱动程序的程序代码公开，等于硬件规格也公开的差不多了。许多厂商不愿意这么做，所以只提供编好的驱动程序，但不提供源代码。

   Android 的重点就是商业应用，Google采用了一些手法来绕过这问题。他们把驱动程序移到 "userspace"，也就是说，把驱动程序变成在 Linux kernel 上头跑，而不是一起跑的东西，这样就可以避过GPL。然后，在 kernel 这边开个小门，让本来不能直接控制到硬件的 "userspace" 程序也可以碰得到，这样只要把"开个小门"的程序代码公布就可以符合GPL协议了。

  这样又有一个问题，在android体系结构里面，Linux kernel是包含驱动的，和这个Hal又有什么区别呢？ 这里，我是这样理解的，Linux kernel里面的驱动是通用驱动，是开源的，厂家把一些功能性的驱动都移到了HAL层里面。不知道这样理解对不对，求证~~

  引入HAL这种方法的巧妙之处在于，Kernel和Android的许可证不一样，前者是GPL许可证，后者是Apache Software License（简称ASL）许可证。GPL许可证规定，对源码的任何修改都必须开源，所以Android开源了，因为它修改了Kernel。而ASL许可证规定，可以随意使用源码，不必开源，所以建筑在Android之上的硬件驱动和应用程序，都可以保持封闭。为了得到更多厂商的支持，Google有意选择了这样做，并且特意修改Kernel，使得原本应该包括在kernel中的某些功能，都被转移到了userspace之中，因此得以避开开源。

                                         图1：hal层

  

 对Hal的理解如上图1，其实这里的Hal层跟windows Hal层很相似，其目的是使得上层应用忽略底层的设备差异，从而使应用程序接口统一。只是这里的Hal层视乎比windows的Hal多完成了一些功能，很多属于更底层驱动的功能，现在被转移进来了。

   Android中，HAL 模块主要以MODULE_ID.platform.so 的名字存放在文件系统的/system/lib/hw/ 目录下面.
  Android为了统一Hal架构.引入了HAL stub的概念，如图2.
  HAL stub 是一种代理人（proxy）的概念，stub 虽然仍是以 *.so的形式存在，但 HAL 已经将 *.so 隐藏起来了。Stub 向 HAL提供操作函数（operations），而 runtime 则是向 HAL 取得特定模块（stub）的 operations，再 callback 这些操作函数。这种以 indirect function call 的动态链接库模型，让HAL stub 变成是一种包含关系，即 HAL 里包含了许许多多的 stub（代理人）。Runtime 只要说明类型，即 module ID，就可以取得操作函数。对于目前的HAL，可以认为Android定义了HAL层结构框架，通过几个接口访问硬件从而统一了调用方式。
简单的说就是上层只拥有访问HAL stub的函数指针，并不需要HAL stub。上层通过HAL module提供的统一接口获取并操作HAL stub，so文件只会被mapping到一个进程，也不存在重复mapping和重入问题。

                              图2：Hal Stub

          有一个不明白的问题就是android对驱动的处理方式有了些改变。这样Google对Linux驱动做了哪些处理？下一步还是要深入Linux内核研究下。 期待高手指点。