本文主要是介绍解读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 修改
- 增加对logger_aio_write()异步I/O的介绍；
- 增加对logger_poll()的讲解；
- 增加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的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
