Android日志系统驱动程序Logger源代码分析
我们知道，在Android系统中，提供了一个轻量级的日志系统，这个日志系统是以驱动程序的形式实现在内核空间的，而在用户空间分别提供了Java接口和C/C++接口来使用这个日志系统，取决于你编写的是Android应用程序还是系统组件。在前面的文章浅谈Android系统开发中LOG的使用中，已经简要地介绍了在Android应用程序开发中Log的使用方法，在这一篇文章中，我们将更进一步地分析Logger驱动程序的源代码，使得我们对Android日志系统有一个深刻的认识。
既然Android 日志系统是以驱动程序的形式实现在内核空间的，我们就需要获取Android内核源代码来分析了，请参照前面在Ubuntu上下载、编译和安装Android最新源代码和在Ubuntu上下载、编译和安装Android最新内核源代码（Linux Kernel）两篇文章，下载好Android源代码工程。Logger驱动程序主要由两个文件构成，分别是：
kernel/common/drivers/staging/android/logger.h
kernel/common/drivers/staging/android/logger.c
接下来，我们将分别介绍Logger驱动程序的相关数据结构，然后对Logger驱动程序源代码进行情景分析，分别日志系统初始化情景、日志读取情景和日志写入情景。
一.Logger驱动程序的相关数据结构。
我们首先来看logger.h头文件的内容：
struct logger_entry是一个用于描述一条Log记录的结构体。len成员变量记录了这条记录的有效负载的长度，有效负载指定的日志记录本身的长度，但是不包括用于描述这个记录的struct logger_entry结构体。回忆一下我们调用android.util.Log接口来使用日志系统时，会指定日志的优先级别Priority、Tag字符串以及Msg字符串，Priority + Tag + Msg三者内容的长度加起来就是记录的有效负载长度了。__pad成员变量是用来对齐结构体的。pid和tid成员变量分别用来记录是哪条进程写入了这条记录。sec和nsec成员变量记录日志写的时间。msg成员变量记录的就有效负载的内容了，它的大小由len成员变量来确定。接着定义两个宏：
#define LOGGER_ENTRY_MAX_LEN (4*1024)
#define LOGGER_ENTRY_MAX_PAYLOAD \
(LOGGER_ENTRY_MAX_LEN - sizeof(struct logger_entry))
从这两个宏可以看出，每条日志记录的有效负载长度加上结构体logger_entry的长度不能超过4K个字节。
logger.h文件中还定义了其它宏，读者可以自己分析，在下面的分析中，碰到时，我们也会详细解释。
再来看logger.c文件中，其它相关数据结构的定义：
结构体struct logger_log就是真正用来保存日志的地方了。buffer成员变量变是用保存日志信息的内存缓冲区，它的大小由size成员变量确定。从misc成员变量可以看出，logger驱动程序使用的设备属于misc类型的设备，通过在Android模拟器上执行cat /proc/devices命令（可参考 在Ubuntu上下载、编译和安装Android最新内核源代码（Linux Kernel）一文），可以看出，misc类型设备的主设备号是10。关于主设备号的相关知识，可以参考 Android学习启动篇一文中提到的Linux Driver Development一书。wq成员变量是一个等待队列，用于保存正在等待读取日志的进程。readers成员变量用来保存当前正在读取日志的进程，正在读取日志的进程由结构体logger_reader来描述。mutex成员变量是一个互斥量，用来保护log的并发访问。可以看出，这里的日志系统的读写问题，其实是一个生产者-消费者的问题，因此，需要互斥量来保护log的并发访问。 w_off成员变量用来记录下一条日志应该从哪里开始写。head成员变量用来表示打开日志文件中，应该从哪一个位置开始读取日志。结构体struct logger_reader用来表示一个读取日志的进程，log成员变量指向要读取的日志缓冲区。list成员变量用来连接其它读者进程。r_off成员变量表示当前要读取的日志在缓冲区中的位置。
struct logger_log结构体中用于保存日志信息的内存缓冲区buffer是一个循环使用的环形缓冲区，缓冲区中保存的内容是以struct logger_entry为单位的，每个单位的组成为：
struct logger_entry | priority | tag | msg
由于是内存缓冲区buffer是一个循环使用的环形缓冲区，给定一个偏移值，它在buffer中的位置由下logger_offset来确定：
#define logger_offset(n) ((n) & (log->size - 1))
二. Logger驱动程序模块的初始化过程分析。
继续看logger.c文件，定义了三个日志设备：
分别是log_main、log_events和log_radio，名称分别LOGGER_LOG_MAIN、LOGGER_LOG_EVENTS和LOGGER_LOG_RADIO，它们的次设备号为MISC_DYNAMIC_MINOR，即为在注册时动态分配。在logger.h文件中，有这三个宏的定义： #define LOGGER_LOG_RADIO "log_radio" /* radio-related messages */
#define LOGGER_LOG_EVENTS "log_events" /* system/hardware events */
#define LOGGER_LOG_MAIN "log_main" /* everything else */
注释说明了这三个日志设备的用途。注册的日志设备文件操作方法为logger_fops：
日志驱动程序模块的初始化函数为logger_init：
logger_init函数通过调用init_log函数来初始化了上述提到的三个日志设备： init_log函数主要调用了misc_register函数来注册misc设备，misc_register函数定义在kernel/common/drivers/char/misc.c文件中： 注册完成后，通过device_create创建设备文件节点。这里，将创建/dev/log/main、/dev/log/events和/dev/log/radio三个设备文件，这样，用户空间就可以通过读写这三个文件和驱动程序进行交互。三. Logger驱动程序的日志记录读取过程分析。
继续看logger.c 文件，注册的读取日志设备文件的方法为logger_read：
注意，在函数开始的地方，表示读取日志上下文的struct logger_reader是保存在文件指针的private_data成员变量里面的，这是在打开设备文件时设置的，设备文件打开方法为logger_open： 新打开日志设备文件时，是从log->head位置开始读取日志的，保存在struct logger_reader的成员变量r_off中。start标号处的while循环是在等待日志可读，如果已经没有新的日志可读了，那么就要读进程就要进入休眠状态，等待新的日志写入后再唤醒，这是通过prepare_wait和schedule两个调用来实现的。如果没有新的日志可读，并且设备文件不是以非阻塞O_NONBLOCK的方式打开或者这时有信号要处理（signal_pending(current)），那么就直接返回，不再等待新的日志写入。判断当前是否有新的日志可读的方法是：
ret = (log->w_off == reader->r_off);
即判断当前缓冲区的写入位置和当前读进程的读取位置是否相等，如果不相等，则说明有新的日志可读。
继续向下看，如果有新的日志可读，那么就，首先通过get_entry_len来获取下一条可读的日志记录的长度，从这里可以看出，日志读取进程是以日志记录为单位进行读取的，一次只读取一条记录。get_entry_len的函数实现如下：
上面我们提到，每一条日志记录是由两大部分组成的，一个用于描述这条日志记录的结构体struct logger_entry，另一个是记录体本身，即有效负载。结构体struct logger_entry的长度是固定的，只要知道有效负载的长度，就可以知道整条日志记录的长度了。而有效负载的长度是记录在结构体struct logger_entry的成员变量len中，而len成员变量的地址与struct logger_entry的地址相同，因此，只需要读取记录的开始位置的两个字节就可以了。又由于日志记录缓冲区是循环使用的，这两个节字有可能是第一个字节存放在缓冲区最后一个字节，而第二个字节存放在缓冲区的第一个节，除此之外，这两个字节都是连在一起的。因此，分两种情况来考虑，对于前者，分别通过读取缓冲区最后一个字节和第一个字节来得到日志记录的有效负载长度到本地变量val中，对于后者，直接读取连续两个字节的值到本地变量val中。这两种情况是通过判断日志缓冲区的大小和要读取的日志记录在缓冲区中的位置的差值来区别的，如果相差1，就说明是前一种情况了。最后，把有效负载的长度val加上struct logger_entry的长度就得到了要读取的日志记录的总长度了。接着往下看，得到了要读取的记录的长度，就调用do_read_log_to_user函数来执行真正的读取动作：
这个函数简单地调用copy_to_user函数来把位于内核空间的日志缓冲区指定的内容拷贝到用户空间的内存缓冲区就可以了，同时，把当前读取日志进程的上下文信息中的读偏移r_off前进到下一条日志记录的开始的位置上。四. Logger驱动程序的日志记录写入过程分析。
继续看logger.c 文件，注册的写入日志设备文件的方法为logger_aio_write：
输入的参数iocb表示io上下文，iov表示要写入的内容，长度为nr_segs，表示有nr_segs个段的内容要写入。我们知道，每个要写入的日志的结构形式为：struct logger_entry | priority | tag | msg
其中， priority、tag和msg这三个段的内容是由iov参数从用户空间传递下来的，分别对应iov里面的三个元素。而logger_entry是由内核空间来构造的：
struct logger_entry header;
struct timespec now;
now = current_kernel_time();
header.pid = current->tgid;
header.tid = current->pid;
header.sec = now.tv_sec;
header.nsec = now.tv_nsec;
header.len = min_t(size_t, iocb->ki_left, LOGGER_ENTRY_MAX_PAYLOAD);
然后调用do_write_log首先把logger_entry结构体写入到日志缓冲区中：
由于logger_entry是内核堆栈空间分配的，直接用memcpy拷贝就可以了。接着，通过一个while循环把iov的内容写入到日志缓冲区中，也就是日志的优先级别priority、日志Tag和日志主体Msg：
由于iov的内容是由用户空间传下来的，需要调用do_write_log_from_user来写入： 这里，我们还漏了一个重要的步骤： 为什么要调用fix_up_reader这个函数呢？这个函数又是作什么用的呢？是这样的，由于日志缓冲区是循环使用的，即旧的日志记录如果没有及时读取，而缓冲区的内容又已经用完时，就需要覆盖旧的记录来容纳新的记录。而这部分将要被覆盖的内容，有可能是某些reader的下一次要读取的日志所在的位置，以及为新的reader准备的日志开始读取位置head所在的位置。因此，需要调整这些位置，使它们能够指向一个新的有效的位置。我们来看一下fix_up_reader函数的实现： 判断log->head和所有读者reader的当前读偏移reader->r_off是否在被覆盖的区域内，如果是，就需要调用get_next_entry来取得下一个有效的记录的起始位置来调整当前位置： 而判断log->head和所有读者reader的当前读偏移reader->r_off是否在被覆盖的区域内，是通过clock_interval函数来实现的： 最后，日志写入完毕，还需要唤醒正在等待新日志的reader进程: /* wake up any blocked readers */
wake_up_interruptible(&log->wq);
至此， Logger驱动程序的主要逻辑就分析完成了，还有其它的一些接口，如logger_poll、logger_ioctl和logger_release函数，比较简单，读取可以自行分析。这里还需要提到的一点是，由于Logger驱动程序模块在退出系统时，是不会卸载的，所以这个模块没有module_exit函数，而对于模块里面定义的对象，也没有用对引用计数技术。
这篇文章着重介绍了Android日志系统在内核空间的实现，在下一篇文章中，我们将接着介绍在用户空间中，提供给Android应用程序使用的Java和C/C++ LOG调用接口的实现过程，敬请关注。