解读Android LOG机制的实现：（4）LOG设备驱动Logger

本文主要是介绍解读Android LOG机制的实现：（4）LOG设备驱动Logger，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

解读Android LOG机制的实现：（4）LOG设备驱动Logger

田海立@CSDN

2011/07/25

 

Android提供了用户级轻量的LOG机制，它的实现贯穿了Java，JNI，本地c/c++实现以及LINUX内核驱动等Android的各个层次，并且足够简单明晰，是一个相当不错的解读案例。本系列文章针对LOG机制的内部实现机理进行解读，本文是系列之四，解读LINUX内核中的设备驱动Logger中实现。Logger是Android为Linux写的一个MISC类型驱动，用循环队列实现了读者/写者。Logger是整个LOG机制实现的核心。

关键字：LINUX驱动，Android，读者/写者，MISC类型驱动，循环队列，等待队列，阻塞I/O

 

Log的驱动是在kernel/drivers/staging/android/Logger.c中实现的。

一、初始化

看一个LINUX驱动，先看它如何初始化的。

static int __init init_log(struct logger_log *log)
{int ret;ret = misc_register(&log->misc);if (unlikely(ret)) {printk(KERN_ERR "logger: failed to register misc ""device for log '%s'!\n", log->misc.name);return ret;}printk(KERN_INFO "logger: created %luK log '%s'\n",(unsigned long) log->size >> 10, log->misc.name);return 0;
}static int __init logger_init(void)
{int ret;ret = init_log(&log_main);if (unlikely(ret))goto out;ret = init_log(&log_events);if (unlikely(ret))goto out;ret = init_log(&log_radio);if (unlikely(ret))goto out;ret = init_log(&log_system);if (unlikely(ret))goto out;out:return ret;
}device_initcall(logger_init);

 

整个Logger驱动的入口点就是Logger_init()，它用init_log(struct logger_log *log)初始化了log_main, log_events, log_radio和 log_system四个logger_log类型的结构，而这四个结构变量分别记录着log的四个存储体。Logger从这四个变量实现了同种设备的四个驱动，而log的驱动是MISC类型的驱动，通过misc_register()向系统注册。四次注册之后，它们对应的MINOR ID将是不同的，Looger也是通过minor来区分是哪一个驱动的。

static struct logger_log *get_log_from_minor(int minor)
{if (log_main.misc.minor == minor)return &log_main;if (log_events.misc.minor == minor)return &log_events;if (log_radio.misc.minor == minor)return &log_radio;if (log_system.misc.minor == minor)return &log_system;return NULL;
}

 

本文将以log_main来讲解Logger驱动的实现。

 

二、关键数据结构

上节中，提到了log_main这个结构体变量，现在来看它的定义。

Log_main里保存了Logger操作必须的变量。buffer指向的真是一个静态数组，用来存放用来读写的数据，Logger用它组成了一个逻辑上的循环队列，写者可以往w_off指向的地方写东西，而一旦有内容，会通知等待队列wq里的读者们来读取内容。因为buffer实现的是循环队列，所以buffer的大小size经常用来做除高位的运算，一定要是一个2次幂的数字。mutex用来保护log_main这个关键资源的。Logger是MISC类型的驱动，它保留着一个miscdevice类型的变量misc。misc里面也有最为关键的file_operations结构，这正是应用程序通过文件操作，与驱动打交道的入口。

 

三、Logger实现的功能

从上面log_main的类型定义就能看出，Logger实现了什么。一句话概括Logger就是实现了读写者，并实现同步操作。不过，Logger的读写者有些特殊，写者写操作不会被阻塞，也不会写满溢出，也就是写时只要有内容可以不停的写，超出Buffer就覆盖旧的[与应用程序具体的写操作结合来看]；读者因为要读的内容为空就会被阻塞挂起，而一旦有内容，所有被挂起的读者都会被唤醒[与应用程序具体的读操作结合来看]。

 

下面看具体实现的时候，就分别从读者和写者的角度去看。

3.1. 写者的实现

看二小节图中的关键结构logger_fops: file_operations，写者的关键实现就看open、release和write这几个函数的实现了，它们被分别赋值给了logger_open() / logger_release() / logger_aio_write()。

logger_open()为写者做的工作就是，通过minor id获得logger_log的实例，然后赋值给函数参数中传递进来的file的private_data中。

logger_release()不需要为写者做的什么工作。

logger_poll()因为写不需要被阻塞。所以这里检测到是因为非因为读而打开的文件（!(file->f_mode &FMODE_READ)）时，就直接返回POLLOUT | POLLWRNORM。无论怎样都可写。

logger_aio_write()是写数据（也就是log信息）的关键。这里是通过异步IO的方法，应用程序通过write()/writev()和aio_write()时都能调用到这个方法。

记录log信息时，写log用的接口是writev()，写的是vec形式的数据，这边写的过程中来的当然也是vec数据了，另外，写具体之间，还写入了类型为logger_entry的数据，来记录时间等信息。写数据到具体buffer时因为存储的位置可能不是连续的，而写在buffer的结尾和开头位置，所以要做判断，并可能要有两次写的buffer的动作。参数里的数据来自用户空间，不能在内核空间直接使用，要用copy_from_user()。写完之后，用wake_up_interruptible(&log->wq)唤醒所有在挂起等待的读者。

 

3.2. 读者的实现

看二小节图中的关键结构logger_fops: file_operations，写者的关键实现就看open、release和read这几个函数的实现了，它们被分别赋值给了logger_open() / logger_release() / logger_read()。

logger_open() 为读者做的工作就是，通过minor id获得logger_log的实例，然后动态申请一个logger_reader类型的读者，并把它加入到logger_log的读者列表readers的结尾，再赋值给函数参数中传递进来的file的private_data中。

logger_release() 与logger_open()对应，将这个读者从读者列表logger_log.readers中移除，并释放掉这个动态申请的实例。

logger_poll()因为应用读之前会调用poll()/select()查看是否可以写。所以这里会用poll_wait()把参数中的poll_table加入到logger_log.wq中，并且如果有内容可读，才设置可读标志|= POLLIN |POLLRDNORM。

logger_read() 是读数据（也就是log信息）的关键。

读数据之前，要先保证有数据，否则该读者就要被挂起在logger_log的等待队列wq上。从具体buffer读数据到时因为存储的位置可能不是连续的，存储在buffer的结尾和开头位置，所以要做判断，并可能要有两次读去buffer的动作。数据来自内核空间，要通过用户空间的参数里传递出去，需要copy_to_user()。

 

3.3 循环队列的实现

这个是数据结构里最经典的案例了，这里不再具体解释如何实现，只是列出重要结构，只是希望读者还记得数据结构里逻辑结构和物理结构的说法。

队列大小：log_main.size
写头：log_main.w_off
读头：logger_reader.r_off
队列为空判断：log_main.w_off == logger_reader.r_off
队列为满判断：不需要

 

3.4 ioctl的实现

Logger提供给应用程序通过ioctl()来获取信息或控制LOGbuffer的功能。Logger是把logger_ioctl通过file_operations注册到文件系统中来实现这一功能的。Logger_ioctl()提供了下列ioctl控制命令：LOGGER_GET_LOG_BUF_SIZE / LOGGER_GET_LOG_LEN/ LOGGER_GET_NEXT_ENTRY_LEN / LOGGER_FLUSH_LOG。实现很简单：

LOGGER_GET_LOG_BUF_SIZE获取Buffer的大小，直接返回logger_log.size即可；

LOGGER_GET_LOG_LEN只对读有效，获取当前LOG的大小，存储连续的话就是log->w_off -reader->r_off，否则就是(log->size -reader->r_off) + log->w_off；

LOGGER_GET_NEXT_ENTRY_LEN获取Entry的长度，只对读有效。

LOGGER_FLUSH_LOG只对写打开有效。所谓FLUSH LOG，直接重置每个reader的r_off，并设置新reader要访问用的head即可。

3.5 阻塞I/O、异步I/O

另文阐述。

 

【修订记录】

2011/07/27 修改

1. 增加对logger_aio_write()异步I/O的介绍；
2. 增加对logger_poll()的讲解；
3. 增加ioctl()的讲述。

【本系列文章】

解读Android LOG机制的实现：（1）LOG的实现架构

        解读LOG机制的实现架构。

解读Android LOG机制的实现：（2）Java域输出LOG

        解读Android的Java程序中如何输出LOG信息到LOG的体系中。

解读Android LOG机制的实现：（3）JNI及NATIVE域写设备文件

        解读android.util.Log的JNI实现，以及在c/c++的本地实现中如何操作设备文件写Log信息。

解读Android LOG机制的实现：（4）LOG设备驱动logger

        解读LINUX内核中的设备驱动Logger中实现。Logger是Android为Linux写的一个MISC类型驱动，用循环队列实现了读者/写者。Logger是整个LOG机制实现的核心。

解读Android LOG机制的实现：（5）获取LOG程序LogCat

        解读应用程序LogCat如何通过对设备文件的open()/select()/read()来获取LOG信息。

解读Android LOG机制的实现：（6）c/c++域使用LOG

        解读Android的c/c++程序中如何使用LOG机制记录LOG信息。

这篇关于解读Android LOG机制的实现：（4）LOG设备驱动Logger的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---