第二章 Android内核和驱动程序(转)

偏执的太偏执、 2022-06-18 00:07 264阅读 0赞

这一章我们来介绍Android系统的核心部分-Android内核。我们说Android系统是基于Linux系统的，最根本的原因就在于Android采用了Linux内核。

# **2.1 Android内核特性** #

Android内核是基于Linux 2.6内核的（目前最新开发版本是2.6.31），它是一个增强内核版本，除了修改部分Bug外，它提供了用于支持Android平台的设备驱动，主要包括：

>  *  **Android Binder**
> 
> 基于OpenBinder框架的一个驱动，用于提供Android平台的进程间通讯（IPC，inter-process communication）。
> 
> *源代码位于  drivers/staging/android/binder.c*
> 
>  *  **Android电源管理（PM）**
> 
> 一个基于标准Linux电源管理系统的轻量级的Android电源管理驱动，针对嵌入式设备做了很多优化。
> 
> *源代码位于*
> 
> *kernel/power/earlysuspend.c  
> kernel/power/consoleearlysuspend.c  
> kernel/power/fbearlysuspend.c  
> kernel/power/wakelock.c  
> kernel/power/userwakelock.c*
> 
>  *  **低内存管理器（**Low Memory Killer**）**
> 
> 相对于Linux标准OOM（Out Of Memory）机制更加灵活，它可以根据需要杀死进程来释放需要的内存。
> 
> *源代码位于  drivers/staging/android/lowmemorykiller.c*
> 
>  *  **匿名共享内存（ashmem）**
> 
> 为进程间提供大块共享内存，同时为内核提供回收和管理这个内存的机制。
> 
> *源代码位于  mm/ashmem.c*
> 
>  *  **Android PMEM（Physical）**
> 
> PMEM用于向用户空间提供连续的物理内存区域，DSP和某些设备只能工作在连续的物理内存上，
> 
> *源代码位于  drivers/misc/pmem.c*
> 
>  *  **Android Logger**
> 
> 一个轻量级的日志设备，用于抓取Android系统的各种日志
> 
> *源代码位于drivers/staging/android/logger.c*
> 
>  *  **Android Alarm**
> 
> 提供了一个定时器用于把设备从睡眠状态唤醒，同时它也提供了一个即使在设备睡眠时也会运行的时钟基准，
> 
> *源代码位于  drivers/rtc/alarm.c*
> 
>  *  **USB Gadget驱动**
> 
> 一个基于标准Linux USB gadget驱动框架的设备驱动，Android的USB驱动是基于gaeget框架的，
> 
> *源代码位于drivers/usb/gadget/*
> 
>  *  **Android Switch**
>  *  **Android Ram Console**
> 
> 为了提供调试功能，Android允许将调试日志信息写入一个被称为RAM Console的设备里，它是一个基于RAM的Buffer。
> 
> *源代码位于  drivers/staging/android/ram\_console.c。*
> 
>  *  **Android timed device**
> 
> 提供了对设备进行定时控制功能，目前支持vibrator和LED设备。
> 
> *源代码位于drivers/staging/android/timed\_output.c(timed\_gpio.c)。*
> 
>  *  **Yaffs2文件系统**
> 
> Android采用Yaffs2作为MTD nand flash文件系统
> 
> *源代码位于fs/yaffs2/目录下。*
> 
> Yaffs2是一个快速稳定的应用于NAND和NOR Flash的跨平台的嵌入式设备文件系统，同其他Flash文件系统相比，Yaffs2使用更小的内存来保存他的运行状态，因此它占用内存小；Yaffs2的垃圾回收非常简单而且快速，因此能达到更好的性能；Yaffs2在大容量的NAND Flash上性能表现尤为明显，非常适合大容量的Flash存储。

下面的列表是Android平台内核源文件：

<table style="width:50%"> 
 <tbody> 
 <tr> 
 <td style="width:380px; height:136px"> drivers/misc/kernel_debugger.c drivers/misc/pmem.c drivers/misc/qemutrace/qemu_trace_sysfs.c drivers/misc/qemutrace/qemu_trace.c drivers/misc/qemutrace/qemu_trace.h drivers/misc/uid_stat.c </td> 
 <td style="width:112px; height:136px"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="width:380px; height:229px"> drivers/staging/android/lowmemorykiller.c drivers/staging/android/logger.c drivers/staging/android/timed_output.h drivers/staging/android/ram_console.c drivers/staging/android/timed_gpio.c drivers/staging/android/logger.h drivers/staging/android/binder.h drivers/staging/android/binder.c drivers/staging/android/timed_output.c drivers/staging/android/timed_gpio.h </td> 
 <td style="width:112px; height:229px"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="width:380px; height:53px"> drivers/rtc/alarm.c drivers/rtc/rtc-goldfish.c </td> 
 <td style="width:112px; height:53px"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="width:380px; height:69px"> drivers/net/pppolac.c drivers/net/ppp_mppe.c drivers/net/pppopns.c </td> 
 <td style="width:112px; height:69px"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="width:380px; height:24px"> drivers/video/goldfishfb.c </td> 
 <td style="width:112px; height:24px"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="width:380px; height:40px"> drivers/switch/switch_class.c drivers/switch/switch_gpio.c </td> 
 <td style="width:112px; height:40px"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="width:380px; height:43px"> drivers/char/dcc_tty.c drivers/char/goldfish_tty.c </td> 
 <td style="width:112px; height:43px"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="width:380px; height:24px"> drivers/watchdog/i6300esb.c </td> 
 <td style="width:112px; height:24px"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="width:380px; height:206px"> drivers/input/misc/gpio_event.c drivers/input/misc/gpio_input.c drivers/input/misc/gpio_output.c drivers/input/misc/keychord.c drivers/input/misc/gpio_axis.c drivers/input/misc/gpio_matrix.c drivers/input/keyreset.c drivers/input/keyboard/goldfish_events.c drivers/input/touchscreen/synaptics_i2c_rmi.c </td> 
 <td style="width:112px; height:206px"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="width:380px; height:116px"> drivers/usb/gadget/android.c drivers/usb/gadget/f_adb.h drivers/usb/gadget/f_mass_storage.h drivers/usb/gadget/f_adb.c drivers/usb/gadget/f_mass_storage.c </td> 
 <td style="width:112px; height:116px"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="width:380px; height:24px"> drivers/mmc/host/goldfish.c </td> 
 <td style="width:112px; height:24px"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="width:380px; height:24px"> drivers/power/goldfish_battery.c </td> 
 <td style="width:112px; height:24px"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="width:380px; height:24px"> drivers/leds/ledtrig-sleep.c </td> 
 <td style="width:112px; height:24px"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="width:380px; height:44px"> drivers/mtd/devices/goldfish_nand_reg.h drivers/mtd/devices/goldfish_nand.c </td> 
 <td style="width:112px; height:44px"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="width:380px; height:107px"> kernel/power/earlysuspend.c kernel/power/consoleearlysuspend.c kernel/power/fbearlysuspend.c kernel/power/wakelock.c kernel/power/userwakelock.c </td> 
 <td style="width:112px; height:107px"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="width:380px; height:24px"> kernel/cpuset.c kernel/cgroup_debug.c kernel/cgroup.c </td> 
 <td style="width:112px; height:24px"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="width:380px; height:24px"> mm/ashmem.c </td> 
 <td style="width:112px; height:24px"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="width:380px; height:381px"> include/linux/ashmem.h include/linux/switch.h include/linux/keychord.h include/linux/earlysuspend.h include/linux/android_aid.h include/linux/uid_stat.h include/linux/if_pppolac.h include/linux/usb/android.h include/linux/wifi_tiwlan.h include/linux/android_alarm.h include/linux/keyreset.h include/linux/synaptics_i2c_rmi.h include/linux/android_pmem.h include/linux/kernel_debugger.h include/linux/gpio_event.h include/linux/wakelock.h include/linux/if_pppopns.h </td> 
 <td style="width:112px; height:381px"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="width:380px; height:24px"> net/ipv4/sysfs_net_ipv4.c net/ipv4/af_inet.c </td> 
 <td style="width:112px; height:24px"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="width:380px; height:24px"> net/ipv6/af_inet6.c </td> 
 <td style="width:112px; height:24px"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="width:380px; height:24px"> net/bluetooth/af_bluetooth.c </td> 
 <td style="width:112px; height:24px"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="width:380px; height:24px"> security/commoncap.c </td> 
 <td style="width:112px; height:24px"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="width:380px; height:24px"> fs/proc/base.c </td> 
 <td style="width:112px; height:24px"> &nbsp; </td> 
 </tr> 
 </tbody> 
</table>

# **2.2 Android 内核配置** #

Android是基于Linux的，对于一个新的设备，我们首先要编译一个支持Android的Kernel，那么如何使你的Kernel Android化呢？除了要移植前面提到的驱动之外，就是如何配置你的Kernel来支持Android平台，这可以参考Goldfish的内核配置文件- arch/arm/configs/goldfish\_defconfig。

一般来说，我们会基于一个平台标准内核配置选项来配置Android内核，你可以根据具体的硬件平台来选择Android内核的配置选项，可以参考下面的Android内核配置列表：

表2-1：Android内核配置选项（Required Enabled）

<table style="width:50%"> 
 <tbody> 
 <tr> 
 <td>ANDROID_PARANOID_NETWORK ASHMEM CONFIG_FB_MODE_HELPERS CONFIG_FONT_8x16 CONFIG_FONT_8x8 CONFIG_YAFFS_SHORT_NAMES_IN_RAM DAB EARLYSUSPEND FB FB_CFB_COPYAREA FB_CFB_FILLRECT FB_CFB_IMAGEBLIT FB_DEFERRED_IO FB_TILEBLITTING HIGH_RES_TIMERS INOTIFY INOTIFY_USER INPUT_EVDEV INPUT_GPIO INPUT_MISC LEDS_CLASS LEDS_GPIO LOCK_KERNEL LkOGGER LOW_MEMORY_KILLER MISC_DEVICES NEW_LEDS NO_HZ POWER_SUPPLY PREEMPT RAMFS RTC_CLASS RTC_LIB SWITCH SWITCH_GPIO TMPFS UID_STAT UID16 USB_FUNCTION USB_FUNCTION_ADB USER_WAKELOCK VIDEO_OUTPUT_CONTROL WAKELOCK YAFFS_AUTO_YAFFS2 YAFFS_FS YAFFS_YAFFS1 YAFFS_YAFFS2</td> 
 </tr> 
 </tbody> 
</table>

表2-2：Android内核配置选项（Required Disabled）

<table style="width:50%"> 
 <tbody> 
 <tr> 
 <td>CONFIG_YAFFS_DISABLE_LAZY_LOAD DNOTIFY</td> 
 </tr> 
 </tbody> 
</table>

表2-3：Android内核配置选项（Recommended Enabled）

<table style="width:50%"> 
 <tbody> 
 <tr> 
 <td>ANDROID_PMEM ANDROID_RAM_CONSOLE ANDROID_RAM_CONSOLE_ERROR_CORRECTION SCHEDSTATS DEBUG_PREEMPT DEBUG_MUTEXES DEBUG_SPINLOCK_SLEEP DEBUG_INFO FRAME_POINTER CPU_FREQ CPU_FREQ_TABLE CPU_FREQ_DEFAULT_GOV_ONDEMAND CPU_FREQ_GOV_ONDEMAND CRC_CCITT EMBEDDED INPUT_TOUCHSCREEN I2C I2C_BOARDINFO LOG_BUF_SHIFT=17 SERIAL_CORE SERIAL_CORE_CONSOLE</td> 
 </tr> 
 </tbody> 
</table>

配置好后，就可以用Toolchain来编译内核了。编译内核比较简单，以Emulator的kernel为例：

\- git clone git://android.kernel.org/kernel/common.git kernel-emulator 
\- cd kernel-emulator 
\- git checkout original/android-goldfish-2.6.29 -b android-goldfish-2.6.29 
\- export ARCH=arm 
\- export CROSS\_COMPILE=arm-eabi- 
\- export PATH=<CROSS\_COMPIL\_TOOLCHAIN\_PATH\_DIR>:$PATH 
\- make goldfish\_defconfig 
\- make

编译完成后就得到了Android Emulator （Goldfish）的内核 *arch/arm/boot/zImage*

## 第一节 Android Binder ##

星期四, 06/10/2010 - 12:11 — william

通常来说，Binder是Android系统中的内部进程通讯（IPC）之一。在Android系统中共有三种IPC机制，分别是：

－标准Linux Kernel IPC接口  
       －标准D-BUS接口  
       －Binder接口

尽管Google宣称Binder具有更加简洁、快速，消耗更小内存资源的优点，但并没有证据表明D-BUS就很差。实际上D-BUS可能会更合适些，或许只是当时Google并没有注意到它吧，或者Google不想使用GPL协议的D-BUS库。我们不去探究具体的原因了，你只要清楚Android系统中支持了多个IPC接口，而且大部分程序使用的是我们并不熟悉的Binder接口。

Binder是OpenBinder的Google精简实现，它包括一个Binder驱动程序、一个Binder服务器及Binder客户端（？）。这里我们只要介绍内核中的Binder驱动的实现。

对于Android Binder，它也可以称为是Android系统的一种RPC（远程过程调用）机制，因为Binder实现的功能就是在本地“执行”其他服务进程的功能的函数调用。不管是IPC也好，还是RPC也好，我们所要知道的就是Android Binder的功能是如何实现的。

*Openbinder介绍*

**2.1.1 Android Binder协议**

Android 的Binder机制是基于OpenBinder ([http://www.angryredplanet.com/~hackbod/openbinder/docs/html/BinderIPCMechanism.html][http_www.angryredplanet.com_hackbod_openbinder_docs_html_BinderIPCMechanism.html])来实现的，是一个OpenBinder的Linux实现。

Android Binder的协议定义在binder.h头文件中，Android的通讯就是基于这样的一个协议的。

*  **Binder Type**

*（描述binder type的功能）*

Android定义了五个（三大类）Binder类型，如下：

> *enum \{  
>    BINDER\_TYPE\_BINDER      = B\_PACK\_CHARS('s', 'b', '\*', B\_TYPE\_LARGE),  
>    BINDER\_TYPE\_WEAK\_BINDER  = B\_PACK\_CHARS('w', 'b', '\*', B\_TYPE\_LARGE),  
>    BINDER\_TYPE\_HANDLE    = B\_PACK\_CHARS('s', 'h', '\*', B\_TYPE\_LARGE),  
>    BINDER\_TYPE\_WEAK\_HANDLE= B\_PACK\_CHARS('w', 'h', '\*', B\_TYPE\_LARGE),  
>    BINDER\_TYPE\_FD              = B\_PACK\_CHARS('f', 'd', '\*', B\_TYPE\_LARGE),  
> \};*

*  **Binder Object**

进程间传输的数据被称为Binder对象（Binder Object），它是一个flat\_binder\_object，定义如下：

> *struct flat\_binder\_object \{  
>     /\* 8 bytes for large\_flat\_header. \*/  
>     unsigned long        type;  
>     unsigned long        flags;  
>     /\* 8 bytes of data. \*/  
>     union \{  
>         void        \*binder;    /\* local object \*/  
>         signed long    handle;        /\* remote object \*/  
>     \};  
>     /\* extra data associated with local object \*/  
>     void            \*cookie;  
> \};*

其中，类型字段描述了Binder 对象的类型，flags描述了传输方式，比如同步、异步等。

> *enum transaction\_flags \{  
>     TF\_ONE\_WAY    = 0x01,    /\* this is a one-way call: async, no return \*/  
>     TF\_ROOT\_OBJECT    = 0x04,    /\* contents are the component's root object \*/  
>     TF\_STATUS\_CODE    = 0x08,    /\* contents are a 32-bit status code \*/  
>     TF\_ACCEPT\_FDS    = 0x10,    /\* allow replies with file descriptors \*/  
> \};*

传输的数据是一个复用数据联合体，对于BINDER类型，数据就是一个binder本地对象，如果是HANDLE类型，这数据就是一个远程的handle对象。该如何理解本地binder对象和远程handle对象呢？其实它们都指向同一个对象，不过是从不同的角度来说。举例来说，假如A有个对象X，对于A来说，X就是一个本地的binder对象；如果B想访问A的X对象，这对于B来说，X就是一个handle。因此，从根本上来说handle和binder都指向X。本地对象还可以带有额外的数据，保存在cookie中。

Binder对象的传递是通过binder\_transaction\_data来实现的，即Binder对象实际是封装在binder\_transaction\_data结构体中。

*  **binder\_transaction\_data**

这个数据结构才是真正要传输的数据。它的定义如下：

> *struct binder\_transaction\_data \{  
>     /\* The first two are only used for bcTRANSACTION and brTRANSACTION,  
>      \* identifying the target and contents of the transaction.  
>      \*/  
>     union \{  
>         size\_t    handle;    /\* target descriptor of command transaction \*/  
>         void    \*ptr;    /\* target descriptor of return transaction \*/  
>     \} target;  
>     void        \*cookie;    /\* target object cookie \*/  
>     unsigned int    code;        /\* transaction command \*/*
> 
>     /\* General information about the transaction. \*/  
>     unsigned int    flags;  
>     pid\_t        sender\_pid;  
>     uid\_t        sender\_euid;  
>     size\_t        data\_size;    /\* number of bytes of data \*/  
>     size\_t        offsets\_size;    /\* number of bytes of offsets \*/
> 
>     /\* If this transaction is inline, the data immediately  
>      \* follows here; otherwise, it ends with a pointer to  
>      \* the data buffer.  
>      \*/  
>     union \{  
>         struct \{  
>             /\* transaction data \*/  
>             const void    \*buffer;  
>             /\* offsets from buffer to flat\_binder\_object structs \*/  
>             const void    \*offsets;  
>         \} ptr;  
>         uint8\_t    buf\[8\];  
>     \} data;  
> \};

结构体中的数据成员target是一个复合联合体对象，请参考前面的关于binder本地对象及handle远程对象的描述。code是一个命令，描述了请求Binder对象执行的操作。

*  **对象的索引和映射**

Binder中的一个重要概念就是对象的映射和索引。就是要把对象从一个进程映射到另一个进程中，以实现线程迁移的概念。前面描述过Binder的一个重要概念是进程/线程迁移，即当一个进程需要同另一个进程通信时，它可以“迁移”远程的进程/线程到本地来执行。对于调用进程来说，看起来就像是在本地执行一样。这是Binder与其他IPC机制的不同点或者说是优点。当然迁移的工作是由Binder驱动来完成的，而实现的基础和核心就是对象的映射和索引。

Binder中有两种索引，一是本地进程地址空间的一个地址，另一个是一个抽象的32位句柄（HANDLE），它们之间是互斥的：所有的进程本地对象的索引都是本地进程的一个地址(address, ptr, binder)，所有的远程进程的对象的索引都是一个句柄（handle）。对于发送者进程来说，索引就是一个远端对象的一个句柄，当Binder对象数据被发送到远端接收进程时，远端接受进程则会认为索引是一个本地对象地址，因此从第三方的角度来说，尽管名称不同，对于一次Binder调用，两种索引指的是同一个对象，Binder驱动则负责两种索引的映射，这样才能把数据发送给正确的进程。

*  **BinderDriverCommandProtocol**

Binder驱动的命令协议（BC\_命令），定义了Binder驱动支持的命令格式及数据定义（协议）。不同的命令所带有的数据是不同的。Binder的命令由binder\_write\_read数据结构描述，它是ioctl命令（BINDER\_WRITE\_READ）的参数。

> *struct binder\_write\_read \{  
>     signed long    write\_size;    /\* bytes to write \*/  
>     signed long    write\_consumed;    /\* bytes consumed by driver \*/  
>     unsigned long    write\_buffer;  
>     signed long    read\_size;    /\* bytes to read \*/  
>     signed long    read\_consumed;    /\* bytes consumed by driver \*/  
>     unsigned long    read\_buffer;  
> \};*

对于写操作，write\_buffer包含了一系列请求线程执行的Binder命令；对于读（返回）操作，read\_buffer包含了一系列线程执行后填充的返回值。

Binder命令（BC\_）用于BINDER\_WRITE\_READ的write操作。

Binder的BC的命令格式是：| CMD | Data... |

<table style="width:80%"> Binder Commands 
 <tbody> 
 <tr> 
 <td>CMD</td> 
 <td>Data Format</td> 
 <td>Notes</td> 
 </tr> 
 <tr> 
 <td>BC_TRANSACTION BC_REPLY</td> 
 <td>binder_transaction_data</td> 
 <td>&nbsp;</td> 
 </tr> 
 <tr> 
 <td>BC_ACQUIRE_RESULT BC_ATTEMPT_ACQUIRE</td> 
 <td>&nbsp;</td> 
 <td>Not implement</td> 
 </tr> 
 <tr> 
 <td>BC_FREE_BUFFER</td> 
 <td>data_ptr</td> 
 <td>ptr to transaction data received on a read</td> 
 </tr> 
 <tr> 
 <td>BC_INCREFS BC_ACQUIRE BC_RELEASE BC_DECREFS</td> 
 <td>int</td> 
 <td>target descriptor</td> 
 </tr> 
 <tr> 
 <td>BC_INCREFS_DONE BC_ACQUIRE_DONE</td> 
 <td>node_ptr | cookie</td> 
 <td>&nbsp;</td> 
 </tr> 
 <tr> 
 <td>BC_REGISTER_LOOPER BC_ENTER_LOOPER BC_EXIT_LOOPER</td> 
 <td>&nbsp;</td> 
 <td>No parameters</td> 
 </tr> 
 <tr> 
 <td>BC_REQUEST_DEATH_NOTIFICATION</td> 
 <td>target_ptr | cookie</td> 
 <td>&nbsp;</td> 
 </tr> 
 <tr> 
 <td>BC_DEAD_BINDER_DONE</td> 
 <td>cookie</td> 
 <td>&nbsp;</td> 
 </tr> 
 </tbody> 
</table>

*  **BinderDriverReturnProtocol**

Binder驱动的响应（返回，BR\_）协议，定义了Binder命令的数据返回格式。同Binder命令协议一样，Binder驱动返回协议也是通过BINDER\_WRITE\_READ ioctl命令实现的，不同的是它是read操作。

Binder BR的命令格式是：| CMD | Data... |

<table style="width:90%"> Binder BR 命令 
 <tbody> 
 <tr> 
 <td>CMDS</td> 
 <td>Data Format</td> 
 <td>Notes</td> 
 </tr> 
 <tr> 
 <td>BR_ERROR</td> 
 <td>int</td> 
 <td>Error code</td> 
 </tr> 
 <tr> 
 <td>BR_OK BR_NOOP BR_SPAWN_LOOPER</td> 
 <td>&nbsp;</td> 
 <td>No parameters</td> 
 </tr> 
 <tr> 
 <td>BR_TRANSACTION BR_REPLY</td> 
 <td>binder_transaction_data</td> 
 <td>the received command</td> 
 </tr> 
 <tr> 
 <td>BR_ACQUIRE_RESULT BR_ATTEMPT_ACQUIRE BR_FINISHED</td> 
 <td>&nbsp;</td> 
 <td>Not implement</td> 
 </tr> 
 <tr> 
 <td>BR_DEAD_REPLY</td> 
 <td>&nbsp;</td> 
 <td>The target of the last transaction is no longer with us. bcTRANSACTION or bcATTEMPT_ACQUIRE</td> 
 </tr> 
 <tr> 
 <td>BR_TRANSACTION_COMPLETE</td> 
 <td>&nbsp;</td> 
 <td>No parameters... Always refers to the last transaction requested (including replies). Note that this will be sent even for asynchronous transactions</td> 
 </tr> 
 <tr> 
 <td>BR_INCREFS BR_ACQUIRE BR_RELEASE BR_DECREFS</td> 
 <td>target_ptr | cookie</td> 
 <td>&nbsp;</td> 
 </tr> 
 <tr> 
 <td>BR_DEAD_BINDER BR_CLEAR_DEATH_NOTIFICATION_DONE</td> 
 <td>cookie</td> 
 <td>&nbsp;</td> 
 </tr> 
 <tr> 
 <td>BR_FAILED_REPLY</td> 
 <td>&nbsp;</td> 
 <td>The the last transaction (either a bcTRANSACTION or a bcATTEMPT_ACQUIRE) failed (e.g. out of memory). &nbsp;</td> 
 </tr> 
 </tbody> 
</table>

*  **Android Binder 进程/线程模型**

*（描述Android的进程模型）*

**2.1.2 驱动接口**

Android Binder设备驱动接口函数是

> *device\_initcall(binder\_init);*

我们知道一般来说设备驱动的接口函数是module\_init和module\_exit，这么做是为了同时兼容支持静态编译的驱动模块（buildin）和动态编译的驱动模块（module）。但是Android的Binder驱动显然不想支持动态编译的驱动，如果你需要将Binder驱动修改为动态的内核模块，可以直接将device\_initcall修改为module\_init，但不要忘了增加module\_exit的驱动卸载接口函数。

*  **binder\_init**

初始化函数首先使用proc\_mkdir创建了一个Binder的proc文件系统的根节点（binder\_proc\_dir\_entry\_root，/proc/binder），并为binder创建了binder proc节点（binder\_proc\_dir\_entry\_proc，/proc/binder/proc），注意不要混淆Linux Proc和Binder Proc。

然后Binder驱动使用misc\_register把自己注册为一个Misc设备（/dev/misc/binder）。

最后，如果驱动成功的创建了/proc/binder根节点，就调用create\_proc\_read\_entry创建只读proc文件：/proc/binder/state，/proc/binder/stats，/proc/binder/transactions，/proc/binder/transaction\_log，/proc/binder/failed\_transaction\_log。

这个初始化函数有个小小的问题，它没有判断Misc设备是否注册成功了，如果注册失败了，那么Binder就不能正常工作了，因此这里应该有个错误处理流程。

**2.1.3 Binder核心数据**

在进一步介绍Binder驱动之前，我们有必要了解一下Binder的核心数据。

*  **binder\_proc**

> *struct binder\_proc \{  
>     struct hlist\_node proc\_node;  
>     struct rb\_root threads;  
>     struct rb\_root nodes;  
>     struct rb\_root refs\_by\_desc;  
>     struct rb\_root refs\_by\_node;  
>     int pid;  
>     struct vm\_area\_struct \*vma;  
>     struct task\_struct \*tsk;  
>     struct files\_struct \*files;  
>     struct hlist\_node deferred\_work\_node;  
>     int deferred\_work;  
>     void \*buffer;  
>     ptrdiff\_t user\_buffer\_offset;  
>     struct list\_head buffers;  
>     struct rb\_root free\_buffers;  
>     struct rb\_root allocated\_buffers;  
>     size\_t free\_async\_space;  
>     struct page \*\*pages;  
>     size\_t buffer\_size;  
>     uint32\_t buffer\_free;  
>     struct list\_head todo;  
>     wait\_queue\_head\_t wait;  
>     struct binder\_stats stats;  
>     struct list\_head delivered\_death;  
>     int max\_threads;  
>     int requested\_threads;  
>     int requested\_threads\_started;  
>     int ready\_threads;  
>     long default\_priority;  
> \};*

binder\_proc用于保存调用binder的各个进程或线程信息，比如线程id、进程id、binder状态信息等。  
*（各个数据的意义？）*

*  **binder\_node**

> *struct binder\_node \{  
>     int debug\_id;  
>     struct binder\_work work;  
>     union \{  
>         struct rb\_node rb\_node;  
>         struct hlist\_node dead\_node;  
>     \};  
>     struct binder\_proc \*proc;  
>     struct hlist\_head refs;  
>     int internal\_strong\_refs;  
>     int local\_weak\_refs;  
>     int local\_strong\_refs;  
>     void \_\_user \*ptr;  
>     void \_\_user \*cookie;  
>     unsigned has\_strong\_ref : 1;  
>     unsigned pending\_strong\_ref : 1;  
>     unsigned has\_weak\_ref : 1;  
>     unsigned pending\_weak\_ref : 1;  
>     unsigned has\_async\_transaction : 1;  
>     unsigned accept\_fds : 1;  
>     int min\_priority : 8;  
>     struct list\_head async\_todo;  
> \};*

*  **binder\_thread**

**2.1.4 用户接口**

驱动程序的一个主要同能就是向用户空间的程序提供操作接口，这个接口是标准的，对于Android Binder驱动，包含的接口有：  
       －Proc接口（/proc/binder）  
*              . /proc/binder/state  
              . /proc/binder/stats  
              . /proc/binder/transactions  
              . /proc/binder/transaction\_log  
              . /proc/binder/failed\_transaction\_log  
              . /proc/binder/proc/*

- 设备接口（/dev/binder）  
*              . binder\_open  
              . binder\_release  
              . binder\_flush  
              . binder\_mmap  
              . binder\_poll  
              . binder\_ioctl*

这些内核接口函数是在驱动程序的初始化函数(binder\_init)中初始化的，感兴趣的读者可以阅读相关函数的实现代码，很简单明了，一共才十几行的代码。

*  **binder\_open**

通常来说，驱动程序的open函数是用户调用驱动接口来使用驱动功能的第一个函数，称为入口函数。同其他驱动一样，对于Android驱动，任何一个进程及其内的所有线程都可以打开一个binder设备。首先来看看Binder驱动是如何打开设备的。

首先，binder驱动分配内存以保存binder\_proc数据结构。

然后，binder填充binder\_proc数据（初始化），增加当前线程/进程的引用计数并赋值给tsk

> *get\_task\_struct(current);  
> proc->tsk = current;*

初始化binder\_proc的队列及默认优先级

> *INIT\_LIST\_HEAD(&proc->todo);  
> init\_waitqueue\_head(&proc->wait);  
> proc->default\_priority = task\_nice(current);*

增加BINDER\_STAT\_PROC的对象计数，并把创建的binder\_proc对象添加到全局的binder\_proc哈希列表中，这样任何一个进程就都可以访问到其他进程的binder\_proc对象了。

> *binder\_stats.obj\_created\[BINDER\_STAT\_PROC\]++;  
> hlist\_add\_head(&proc->proc\_node, &binder\_procs);*

把当前进程/线程的线程组的pid（pid指向线程id）赋值给proc的pid字段，可以理解为一个进程id（thread\_group指向线程组中的第一个线程的task\_struct结构）。同时把binder\_proc对象指针赋值给filp的private\_data对象保存起来。

> *proc->pid = current->group\_leader->pid;  
> INIT\_LIST\_HEAD(&proc->delivered\_death);  
> filp->private\_data = proc;*

最后，在bindr proc目录中创建只读文件（/proc/binder/proc/$pid）用来输出当前binder proc对象的状态。

这里要注意的是，proc->pid字段，按字面理解它应该是保存当前进程/线程的id，但实际上它保存的是线程组的pid，也就是线程组中的第一个线程的pid（等于tgid，进程id）。

这样当一个进程或线程打开一个binder设备时，驱动就会在内核中为其创建binder\_proc结构来保存打开此设备的进程/线程信息。

*  **binder\_release**

binder\_release是一个驱动的出口函数，当进程退出(exit)时，进程需要显示或隐式的调用release函数来关闭打开的文件。Release函数一般来清理进程的内核数据，释放申请的内存。

Binder驱动的release函数相对比较简单，它删除open是创建的binder proc文件，然后调度一个workqueue来释放这个进程/线程的binder\_proc对象（BINDER\_DEFERRED\_RELEASE）。这里要提的一点就是使用workqueue（deffered）可以提高系统的响应速度和性能，因为Android Binder的release及flush等操作是一个复杂费事的任务，而且也没有必要在系统调用里完成它，因此最好的方法是延迟执行这个费时的任务。其实在中断处理函数中我们经常要把一些耗时的操作放到底半部中处理（bottom half），这是一样的道理。

当然真正的释放工作是在binder\_deferred\_release函数里完成的，后面在做详尽的介绍。

*workqueue是Linux系统中延迟执行任务的一种机制*

*  **binder\_flush**

flush操作在关闭一个设备文件描述符拷贝时被调用，Binder的flush函数十分简单，它只是简单的调度一个workqueue执行BINDER\_DEFERRED\_FLUSH操作。

*  **binder\_mmap**

mmap（memory map）用于把设备内存映射到用户进程地址空间中，这样就可以像操作用户内存那样操作设备内存。（还有一种说法，mmap用于把用户进程地址空间映射到设备内存上，尽管说法不同，但是说的是同一个事情）

Binder设备对内存映射是有些限制的，比如binder设备最大能映射4M的内存区域；binder不能映射具有写权限的内存区域。

不同于一般的设备驱动，大多的设备映射的设备内存是设备本身具有的，或者在驱动初始化时由vmalloc或kmalloc等内核内存函数分配的，Binder的设备内存是在mmap操作时分配的，分配的方法是先在内核虚拟映射表上获取一个可以使用的区域，然后分配物理页，并把物理页映射到获取的虚拟空间上。由于设备内存是在mmap操作中实现的，因此每个进程/线程只能做映射操作一次，其后的操作都会返回错误。

具体来说，binder\_mmap首先检查mmap调用是否合法，即是否满足binder内存映射的条件，主要检查映射内存的大小、flags，是否是第一次调用。

> *if ((vma->vm\_end - vma->vm\_start) > SZ\_4M)  
> vma->vm\_end = vma->vm\_start + SZ\_4M;  
> if (vma->vm\_flags & FORBIDDEN\_MMAP\_FLAGS) \{  
> …  
> \}  
> vma->vm\_flags = (vma->vm\_flags | VM\_DONTCOPY) & ~VM\_MAYWRITE;  
> if (proc->buffer) \{  
> …  
> \}*

然后，binder驱动从系统申请可用的虚拟内存空间（注意不是物理内存空间），这是通过get\_vm\_area内核函数实现的：（get\_vm\_area是一个内核，功能是在内核中申请并保留一块连续的内核虚拟内存空间区域）

> *area = get\_vm\_area(vma->vm\_end - vma->vm\_start, VM\_IOREMAP);  
> proc->buffer = area->addr;  
> proc->user\_buffer\_offset = vma->vm\_start - (uintptr\_t)proc->buffer;*

然后根据请求映射的内存空间大小，分配binder核心数据结构binder\_proc的pages成员，它主要用来保存指向申请的物理页的指针。

> *proc->pages = kzalloc(sizeof(proc->pages\[0\]) \* ((vma->vm\_end - vma->vm\_start) / PAGE\_SIZE), GFP\_KERNEL);  
> proc->buffer\_size = vma->vm\_end - vma->vm\_start;*

一切都准备就绪了，现在开始分配物理内存（page）了。这是通过binder驱动的帮助函数binder\_update\_page\_range来实现的。尽管名字上称为update page，但实际上它是在分配物理页并映射到刚才保留的虚拟内存空间上。在这里，Binder使用alloc\_page分配页面，使用map\_vm\_area为分配的内存做映射关系，使用vm\_insert\_page把分配的物理页插入到用户vma区域。

> *\*page = alloc\_page(GFP\_KERNEL | \_\_GFP\_ZERO);  
> tmp\_area.addr = page\_addr;  
> tmp\_area.size = PAGE\_SIZE + PAGE\_SIZE /\* guard page? \*/;  
> page\_array\_ptr = page;  
> ret = map\_vm\_area(&tmp\_area, PAGE\_KERNEL, &page\_array\_ptr);  
> user\_page\_addr = (uintptr\_t)page\_addr + proc->user\_buffer\_offset;  
> ret = vm\_insert\_page(vma, user\_page\_addr, page\[0\]);*
> 
> *注：alloc\_page, map\_vm\_area和vm\_insert\_page都是Linux内核中内存相关函数。*

当然，这里会使用到的核心数据结构binder\_proc，用到的主要域是

> buffer                            记录binder\_proc的内核虚拟地址的首地址  
> buffer\_size                    记录binder\_proc的虚拟地址的大小  
> user\_buffer\_offset        记录binder\_proc的用户地址偏移，即用户进程vma地址与binder申请的vma地址的偏差  
> pages                            记录指向binder\_proc物理页（struct page）的指针（二维指针）  
> free                      
> free\_async\_space          
> files                                记录进程的struct file\_struct 结构  
> vma                                记录用户进程的vma结构

显然，这些都同内存相关。

*  **binder\_poll**

poll函数是非阻塞型IO（select，poll调用）的内核驱动实现，所有支持非阻塞IO操作的设备驱动都需要实现poll函数。

Binder的poll函数仅支持设备是否可非阻塞的读（POLLIN），这里有两种等待任务，一种是一种是proc\_work，另一种是thread\_work。同其他驱动的poll实现一样，这里也是通过调用poll\_wait函数来实现的，这里就不多做叙述了。

> *poll\_wait(filp, &thread->wait, wait);*

这里需要明确提的一点就是这里调用了下面的函数来取得当前进程/线程的thread对象：

> *thread = binder\_get\_thread(proc);*

特别要指出的，也是很重要的一点，就是这个函数实际上在为服务进程的线程池创建对应的thread对象。后面还会详细讲解这个函数。

*  **binder\_ioctl**

这个函数是Binder的最核心部分，Binder的功能就是通过ioctl命令来实现的。Binder的ioctl命令共有7个，定义在ioctl.h头文件中：

> *\#define BINDER\_WRITE\_READ               \_IOWR('b', 1, struct binder\_write\_read)  
> \#define BINDER\_SET\_IDLE\_TIMEOUT         \_IOW('b', 3, int64\_t)  
> \#define BINDER\_SET\_MAX\_THREADS          \_IOW('b', 5, size\_t)  
> \#define BINDER\_SET\_IDLE\_PRIORITY        \_IOW('b', 6, int)  
> \#define BINDER\_SET\_CONTEXT\_MGR          \_IOW('b', 7, int)  
> \#define BINDER\_THREAD\_EXIT              \_IOW('b', 8, int)  
> \#define BINDER\_VERSION                  \_IOWR('b', 9, struct binder\_version)*

首先要说明的是*BINDER\_SET\_IDLE\_TIMEOUT* 和 *BINDER\_SET\_IDLE\_PRIORITY*在目前的Binder驱动中没有实现。

这里最重要的就是*BINDER\_WRITE\_READ*命令，它是Binder驱动核心的核心，Binder IPC机制主要是通过这个命令来实现的。下面我们首先来介绍简单的用于设置Binder驱动参数的几个ioctl命令，最后着重讲述*BINDER\_WRITE\_READ*命令。

**1. BINDER\_SET\_MAX\_THREADS**

这个ioctl命令用于设置进程的Biner对象所支持的最大线程数。设置的值保存在binder\_proc结构的max\_threads成员里。

**2. BINDER\_SET\_CONTEXT\_MGR**

在这里会引入Binder的另一个核心数据binder\_node。从功能上看，只有一个进程/线程能成功设置binder\_context\_mgr\_node对象，这个进程被称为Context Manager（context\_mgr）。当然，也只有创建binder\_context\_mgr\_node对象的Binder上下文管理进程/线程才有权限重新设置这个对象。进程的权限（cred->euid）保存在binder\_context\_mgr\_uid对象里。

> *binder\_context\_mgr\_uid = current->cred->euid;*

从接口的角度来说，这是一个进程想要成为一个Context Manager的唯一接口。一个Context Manager进程需要为binder\_proc创建一个binder\_node类型的节点。节点是通过*binder\_new\_node*函数来创建的，我们在后面在详细讲解这个函数。节点创建成功后内核会初始化节点的部分数据（*weak\_ref*和*strong\_ref*）。

> *binder\_context\_mgr\_node->local\_weak\_refs++;  
> binder\_context\_mgr\_node->local\_strong\_refs++;  
> binder\_context\_mgr\_node->has\_strong\_ref = 1;  
> binder\_context\_mgr\_node->has\_weak\_ref = 1;*

binder\_proc成员node是binder\_node的根节点，这是一棵红黑树（一种平衡二叉树）。  
现在来看看binder\_new\_node函数，它首先根据规则找到第一个页节点作为新插入的节点的父节点（规则就是binder\_node的指针对象，后面还会遇到）。

> *while (\*p) \{ 
>     parent = \*p; 
>     node = rb\_entry(parent, struct binder\_node, rb\_node); 
>     if (ptr < node->ptr) 
>         p = &(\*p)->rb\_left; 
>     else if (ptr > node->ptr) 
>         p = &(\*p)->rb\_right; 
>     else 
>         return NULL; 
> \}*

找到节点了，那么调用内核函数创建并插入节点吧。

> *node = kzalloc(sizeof(\*node), GFP\_KERNEL);  
> binder\_stats.obj\_created\[BINDER\_STAT\_NODE\]++;  
> rb\_link\_node(&node->rb\_node, parent, p);  
> rb\_insert\_color(&node->rb\_node, &proc->nodes);*

*注：rb\_link\_node和rb\_insert\_color都是内核红黑树函数，rb\_link\_node是一个内联函数，它把新节点插入到红黑树中的指定父节点下。rb\_insert\_color节把已经插入到红黑树中的节点调整并融合到红黑树中（参考根据红黑树规则）。*

插入完成后，做最后的初始化工作，这里着重说明两点，一是把binder\_proc对象指针保存在binder\_node对象里，二是初始化node对象的链表头指针。

> *node->proc = proc;  
> node->ptr = ptr;  
> node->cookie = cookie;  
> node->work.type = BINDER\_WORK\_NODE;  
> INIT\_LIST\_HEAD(&node->work.entry);  
> INIT\_LIST\_HEAD(&node->async\_todo);*

*描述Context Manager的作用是什么呢？*

**3. BINDER\_THREAD\_EXIT**

通过调用binder\_free\_thread终止并释放binder\_thread对象及其binder\_transaction事务。  
*（需要更新，详细描述函数功能）  
biner\_thread会在后面说明，功能是什么？*

**4. BINDER\_VERSION**

读取当前Binder驱动支持的协议版本号。

**5. BINDER\_WRITE\_READ**

前面提到，这个ioctl命令才是Binder最核心的部分，Android Binder的IPC机制就是通过这个接口来实现的。我们在这里来介绍binder\_thread对象，其实在前面已经见到过了，但是因为它与这个接口更加紧密，因此我们把它拿到这里来介绍。

每一个进程的binder\_proc对象都有一个binder\_thread对象（proc->threads.rb\_node节点），进程/线程的id(pid)就保存在binder\_thread结构的pid成员里。Binder\_thread对象是在binder\_get\_thread函数中创建的，ioctl函数在入口处会调用它来取得或创建binder\_thread对象

> *thread = binder\_get\_thread(proc);*

binder\_thread对象保存在binder\_proc对象的thread成员里，同binder\_node一样，它是一棵红黑树。首先我们先来看一下binder\_get\_thread函数。这个函数还是比较简单的，它遍历thread树找到同当前进程相关的binder\_thread对象，判断条件就是当前进程/线程的pid要等于thread对象里记录的pid，看下面的代码：

> *while (\*p) \{ 
>     parent = \*p; 
>     thread = rb\_entry(parent, struct binder\_thread, rb\_node); 
>     if (current->pid < thread->pid) 
>         p = &(\*p)->rb\_left; 
>     else if (current->pid > thread->pid) 
>         p = &(\*p)->rb\_right; 
>     else 
>         break; 
> \}*

如果找到了binder\_thread对象，就直接返回该对象。如果没有找到，就说明当前进程/线程的binder\_thread对象还没有创建，创建一个新的binder\_thread节点并插入到红黑树中，返回这个新创建的binder\_thread对象。当然，这里还要对binder\_thread对象最一个初始化工作

> *thread = kzalloc(sizeof(\*thread), GFP\_KERNEL);  
> binder\_stats.obj\_created\[BINDER\_STAT\_THREAD\]++;  
> thread->proc = proc;  
> thread->pid = current->pid;  
> init\_waitqueue\_head(&thread->wait);  
> INIT\_LIST\_HEAD(&thread->todo);  
> rb\_link\_node(&thread->rb\_node, parent, p);  
> rb\_insert\_color(&thread->rb\_node, &proc->threads);  
> thread->looper |= BINDER\_LOOPER\_STATE\_NEED\_RETURN;  
> thread->return\_error = BR\_OK;  
> thread->return\_error2 = BR\_OK;*

在介绍BINDER\_WRITE\_READ之前，我们先来看一下接口的参数，我们知道，每一个ioctl命令都可以有一个数据参数，BINDER\_WRITE\_READ的参数是一个binder\_write\_read类型的数据结构，它描述了可读写的数据，BINDER\_WRITE\_READ就是根据它的具体内容来做写操作或是读操作。

具体的读写操作是通过两个核心函数来实现的，分别是binder\_thread\_write和binder\_thread\_read。

> if (bwr.write\_size > 0) \{  
>     ret = binder\_thread\_write(proc, thread, (void \_\_user \*)bwr.write\_buffer, bwr.write\_size, &bwr.write\_consumed);  
> \}  
> if (bwr.read\_size > 0) \{  
>     ret = binder\_thread\_read(proc, thread, (void \_\_user \*)bwr.read\_buffer, bwr.read\_size, &bwr.read\_consumed,  
>     filp->f\_flags & O\_NONBLOCK);  
> \}

Binder协议的命令（BC\_和BR\_）就是通过这个BINDER\_WRITE\_READ ioctl接口实现的，下面我们具体来看一下这些命令的实现

[http_www.angryredplanet.com_hackbod_openbinder_docs_html_BinderIPCMechanism.html]: http://www.angryredplanet.com/%7Ehackbod/openbinder/docs/html/BinderIPCMechanism.html