logger机制是在android系统中提供的一个轻量级的日志系统，这个日志系统是以驱动程序的形式在内核空间实现的，在用户空间分别提供了java接口和c/c++接口来使用这个日志系统，使用的接口取决于编写的是android应用程序还是系统组件。
下面我准备从应用开发和源码分析两部分来分析安卓的logger机制。
这一部分将简要地介绍一下在android应用程序开发中log的使用方法
在程序开发过程中，log是广泛使用的用来记录程序执行过程的机制，它既可以用于程序调试，也可以用于产品运营中的事件记录。
在android系统中，提供了简单、便利的log机制，开发人员可以方便地使用。下面我将介绍在android内核空间和用户空间中log的使用和查看方法。
android内核是基于linux kernel 2.36的，因此，linux
kernel的log机制同样适合于android内核，这就是与c语言的printf齐名的printk。与printf类似，printk提供格式化输入功能，同时，它也具有所有log机制的特点——提供日志级别过虑功能。
printk提供了8种日志级别（<linux/kernel.h>）：
#define kern_emerg "<0>"
/* system is unusable */
#define kern_alert "<1>"
/* action must be taken immediately */
#define kern_crit "<2>"
/* critical conditions */
#deinfe kern_err "<3>"
/* error conditions */
#deinfe kern_warning "<4>"
/* warning conditions */
#deinfe kern_notice "<5>" /* normal but significant condition */
#deinfe kern_info "<6>"
/* informational */
#deinfe kern_debug "<7>"
/* debug-level messages */
printk的使用方法：
//kern_alert表示日志级别，后面紧跟着格式化字符串。
printk(kern_alert"this
is the log printed by printk in linux kernel space.");
在android系统中，printk输出的日志信息保存在/proc/kmsg中，要查看/proc/kmsg的内容，需要在后台中运行模拟器：
user-name@machine-name:~/android$ emulator &
启动adb shell工具：
user-name@machine-name:~/android$ adb shell
查看/proc/kmsg文件：
root@android:/# cat /proc/kmsg
android系统在用户空间中提供了轻量级的logger日志系统，它是在内核中实现的一种设备驱动，与用户空间的logcat工具配合使用能够方便地跟踪调试程序。在android系统中，分别为c/c++和java语言提供两种不同的logger访问接口。
android系统中的c/c++日志接口是通过宏来使用的。
在system/core/include/android/log.h定义了日志的级别：
/*
* android log priority values, in ascending priority order.
*/
typedefenum
android_logpriority{
android_log_unknown
=0,
android_log_default, /*
only for setminpriority() */
android_log_verbose,
android_log_debug,
android_log_info,
android_log_warn,
android_log_error,
android_log_fatal,
android_log_silent,/*
only for setminpriority(); must be last */
}
android_logpriority;
在system/core/include/cutils/log.h中，定义了对应的宏。
如对应于android_log_verbose的宏logv：
* this is the local tag used for the following simplified
* logging macros. you can change this preprocessor definition
* before using the other macros to change the tag.
#ifndef log_tag
#define log_tag null
#endif
* simplified macro to send a verbose log message using the current log_tag.
#ifndef logv
#if log_ndebug
#define logv(...) ((void)0)
#else
#define logv(...) ((void)log(log_verbose, log_tag, __va_args__))
* basic log message macro.
*
* example:
* log(log_warn, null, "failed with error %d", errno);
* the second argument may be null or "" to indicate the "global" tag.
#ifndef log
#define log(priority, tag, ...) \
log_pri(android_##priority, tag, __va_args__)
* log macro that allows you to specify a number for priority.
#ifndef log_pri
#define log_pri(priority, tag, ...) \
android_printlog(priority, tag, __va_args__)
* ================================================================
* the stuff in the rest of this file should not be used directly.
#define android_printlog(prio, tag, fmt...) \
__android_log_print(prio, tag, fmt)
因此，如果要使用c/c++日志接口，只要定义自己的log_tag宏和包含头文件system/core/include/cutils/log.h就可以了：
#define log_tag "my log tag"
#include <cutils/log.h>
例如使用logv：
logv("this is the log printed by logv in androiduser space.");
android系统在frameworks层中定义了log接口（frameworks/base/core/java/android/util/log.java）：
................................................
publicfinalclass
log{
/**
* priority constant for the println method; use log.v.
*/
publicstaticfinalint
verbose=2;
* priority constant for the println method; use log.d.
debug=3;
* priority constant for the println method; use log.i.
info=4;
* priority constant for the println method; use log.w.
warn=5;
* priority constant for the println method; use log.e.
error=6;
* priority constant for the println method.
assert=7;
.....................................................
publicstaticint
v(string tag,
string msg){
return
println_native(log_id_main,
verbose, tag,
msg);
}
string msg, throwable tr){
msg +'\n'+
getstacktracestring(tr));
d(string tag,
debug, tag,
i(string tag,
info, tag,
w(string tag,
warn, tag,
throwable tr){
e(string tag,
error, tag,
..................................................................
/**@hide
*/publicstaticnativeint
println_native(int
bufid,
int
priority, string tag,
string msg);
因此，如果要使用java日志接口，只要在类中定义的log_tag常量和引用android.util.log就可以了：
private static final string log_tag ="my_log_tag";
log.i(log_tag, "this is the log printed by log.i inandroid user space.");
log.e(log_tag, "this is the logprinted by log.e in android user space.");
要查看这些log的输出，可以配合logcat工具。如果是在eclipse环境（adt）下运行，直接在eclipse就可以查看了：
user-name@machine-name:~/android$ emulator &
启动adb shell工具：
user-name@machine-name:~/android$ adb shell
使用logcat命令查看日志：
root@android:/ # logcat
这样就可以看到输出的日志了。
以上是logger在应用开发中的使用的简单分析，除了logger在应用开发中的使用，我将更进一步地分析logger驱动程序的源代码，更加深刻的认识android日志系统。
因为android日志系统是以驱动程序的形式实现在内核空间的，所以需要获取android内核源代码来分析。在下载好android源代码工程中，logger驱动程序主要由两个文件构成，分别是：
kernel/common/drivers/staging/android/logger.h
kernel/common/drivers/staging/android/logger.c
接下来，我将首先分析logger驱动程序的相关数据结构，然后对logger驱动程序源代码的使用情景进行分析，比如日志系统初始化情景、日志读取情景和日志写入情景。
#ifndef _linux_logger_h
#define _linux_logger_h
#include <linux/types.h>
#include <linux/ioctl.h>
struct
logger_entry {
__u16
len; /*
length of the payload */
__pad; /*
no matter what, we get 2 bytes of padding */
__s32
pid; /*
generating process's pid */
tid; /*
generating process's tid */
sec; /*
seconds since epoch */
nsec; /*
nanoseconds */
char msg[0];/*
the entry's payload */
};
#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 */
#define logger_entry_max_len (4*1024)
#define logger_entry_max_payload \
(logger_entry_max_len - sizeof(struct logger_entry))
#define __loggerio 0xae
#define logger_get_log_buf_size _io(__loggerio, 1)
/* size of log */
#define logger_get_log_len _io(__loggerio, 2)
/* used log len */
#define logger_get_next_entry_len _io(__loggerio, 3)
/* next entry len */
#define logger_flush_log _io(__loggerio, 4)
/* flush log */
#endif/*
_linux_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成员变量来确定。
接着还定义了两个宏：
(logger_entry_max_len - sizeof(struct logger_entry))
从这两个宏可以看出，每条日志记录的有效负载长度加上结构体logger_entry的长度不能超过4k个字节。
logger.h文件中还定义了其它宏，这里就不一一分析了。
再来看logger.c文件中，其它相关数据结构的定义：
* struct logger_log - represents a specific log, such as 'main' or 'radio'
* this structure lives from module insertion until module removal, so it does
* not need additional reference counting. the structure is protected by the
* mutex 'mutex'.
logger_log {
unsignedchar* buffer;/*
the ring buffer itself */
struct
miscdevice misc; /*
misc device representing the log */
wait_queue_head_t
wq;/*
wait queue for readers */
list_head readers;/*
this log's readers */
mutex mutex; /*
mutex protecting buffer */
size_t
w_off; /*
current write head offset */
head; /*
new readers start here */
size_t size; /*
size of the log */
* struct logger_reader - a logging device open for reading
* this object lives from open to release, so we don't need additional
* reference counting. the structure is protected by log->mutex.
logger_reader {
logger_log* log; /*
associated log */
list_head list; /*
entry in logger_log's list */
size_t r_off; /*
current read head offset */
/* logger_offset - returns index 'n' into the log via (optimized) modulus */
#define logger_offset(n) ((n) & (log->size - 1))
struct logger_log是真正用来保存日志的结构体。
buffer成员变量是用于保存日志信息的内存缓冲区，它的大小由size成员变量确定。
从misc成员变量可以看出，logger驱动程序使用的设备属于misc类型的设备，通过在android模拟器上执行cat
/proc/devices命令，可以看出，misc类型设备的主设备号是10。
wq成员变量是一个等待队列，用于保存正在等待读取日志的进程。
readers成员变量用来保存当前正在读取日志的进程，正在读取日志的进程由结构体logger_reader来描述。
mutex成员变量是一个互斥量，用来保护log的并发访问。因为可以看出，这里的日志系统的读写问题，其实是一个生产者-消费者的问题，因此，需要互斥量来保护log的并发访问。
w_off成员变量用来记录下一条日志应该从哪里开始写。
head成员变量用来表示打开日志文件中，应该从哪一个位置开始读取日志。
struct logger_reader是用来表示一个读取日志的进程的结构体，log成员变量指向要读取的日志缓冲区。list成员变量用来连接其它读者进程。r_off成员变量表示当前要读取的日志在缓冲区中的位置。
struct logger_log结构体中用于保存日志信息的内存缓冲区buffer是一个循环使用的环形缓冲区，缓冲区中保存的内容是以struct
logger_entry为单位的，每个单位的组成为：
structlogger_entry | priority | tag | msg
由于是内存缓冲区buffer是一个循环使用的环形缓冲区，给定一个偏移值，它在buffer中的位置由下logger_offset来确定：
#definelogger_offset(n) ((n) & (log->size -1))
logger.c文件中定义了三个日志设备：
* defines a log structure with name 'name' and a size of 'size' bytes, which
* must be a power of two, greater than logger_entry_max_len, and less than
* long_max minus logger_entry_max_len.
#define define_logger_device(var, name, size) \
static unsigned char _buf_ ## var[size]; \
static struct logger_log var = { \
.buffer = _buf_ ## var, \
.misc = { \
.minor = misc_dynamic_minor, \
.name = name, \
.fops = &logger_fops, \
.parent = null, \
}, \
.wq = __wait_queue_head_initializer(var .wq), \
.readers = list_head_init(var .readers), \
.mutex = __mutex_initializer(var .mutex), \
.w_off = 0, \
.head = 0, \
.size = size, \
define_logger_device(log_main,
logger_log_main,64*1024)
define_logger_device(log_events,
logger_log_events,256*1024)
define_logger_device(log_radio,
logger_log_radio,64*1024)
分别是log_main、log_events和log_radio，名称分别logger_log_main、logger_log_events和logger_log_radio，它们的次设备号为misc_dynamic_minor，即为在注册时动态分配。
在logger.h文件中，有这三个宏的定义：
#definelogger_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：
staticstruct
file_operations logger_fops={
.owner=
this_module,
.read=
logger_read,
.aio_write=
logger_aio_write,
.poll=
logger_poll,
.unlocked_ioctl=
logger_ioctl,
.compat_ioctl=
.open=
logger_open,
.release=
logger_release,
日志驱动程序模块的初始化函数为logger_init：
staticint
__init logger_init(void)
{
int
ret;
ret
= init_log(&log_main);
if(unlikely(ret))
goto
out;
= init_log(&log_events);
= init_log(&log_radio);
out:
return
device_initcall(logger_init);
logger_init函数通过调用init_log函数来初始化了上述提到的三个日志设备：
__init init_log(struct
logger_log *log)
= misc_register(&log->misc);
if(unlikely(ret)){
printk(kern_err"logger:
failed to register misc "
"device
for log '%s'!\n", log->misc.name);
printk(kern_info"logger:
created %luk log '%s'\n",
(unsignedlong)
log->size>>10,
log->misc.name);
return0;
init_log函数主要调用了misc_register函数来注册misc设备，misc_register函数定义在kernel/common/drivers/char/misc.c文件中：
/**
* misc_register
- register a miscellaneous device
* @misc: device structure
* register a miscellaneous device with the kernel.
if the minor
* number is set to %misc_dynamic_minor a minor number
is assigned
* and placed in the minor field of the structure.
for other cases
* the minor number requested is used.
* the structure passed is linked into the kernel and
may not be
* destroyed until it has been unregistered.
* a zero is returned on success and a negative errno
code for
* failure.
int misc_register(struct
miscdevice * misc)
struct
miscdevice*c;
dev_t dev;
err=0;
init_list_head(&misc->list);
mutex_lock(&misc_mtx);
list_for_each_entry(c,&misc_list,
list){
if(c->minor==
misc->minor){
mutex_unlock(&misc_mtx);
return-ebusy;
}
}
if(misc->minor==
misc_dynamic_minor){
int
i= dynamic_minors;
while(--i>=0)
if((misc_minors[i>>3]&(1<<(i&7)))==0)
break;
if(i<0){
misc->minor=
i;
if(misc->minor<
dynamic_minors)
misc_minors[misc->minor>>3]|=1<<(misc->minor&7);
dev
= mkdev(misc_major,
misc->minor);
misc->this_device=
device_create(misc_class,
misc->parent,
dev,null,
"%s",
misc->name);
if(is_err(misc->this_device)){
err
= ptr_err(misc->this_device);
goto
/*
* add it to the front, so that later devices can "override"
* earlier defaults
list_add(&misc->list,&misc_list);
out:
mutex_unlock(&misc_mtx);
err;
注册完成后，通过device_create创建设备文件节点。这里，将创建/dev/log/main、/dev/log/events和/dev/log/radio三个设备文件，这样，用户空间就可以通过读写这三个文件和驱动程序进行交互。
在logger.c文件中，注册的读取日志设备文件的方法为logger_read：
* logger_read - our log's read() method
* behavior:
* - o_nonblock works
* - if there are no log entries to read, blocks until
log is written to
* - atomically reads exactly one log entry
* optimal read size is logger_entry_max_len. will set errno to einval if read
* buffer is insufficient to hold next entry.
static
ssize_t logger_read(struct
file *file,char
__user*buf,
size_t count,
loff_t*pos)
logger_reader*reader=
file->private_data;
logger_log*log=
reader->log;
ssize_t ret;
define_wait(wait);
start:
while(1){
prepare_to_wait(&log->wq,&wait,
task_interruptible);
mutex_lock(&log->mutex);
ret
=(log->w_off==
reader->r_off);
mutex_unlock(&log->mutex);
if(!ret)
break;
if(file->f_flags&
o_nonblock){
ret
=-eagain;
if(signal_pending(current)){
=-eintr;
schedule();
finish_wait(&log->wq,&wait);
if(ret)
mutex_lock(&log->mutex);
/*
is there still something to read or did we race? */
if(unlikely(log->w_off==
reader->r_off)){
start;
get the size of the next entry */
= get_entry_len(log,
if(count<
ret){
=-einval;
get exactly one entry from the log */
= do_read_log_to_user(log,
reader, buf,
ret);
mutex_unlock(&log->mutex);
需要注意的是，在函数开始的地方，表示读取日志上下文的structlogger_reader是保存在文件指针的private_data成员变量里面的，这是在打开设备文件时设置的，设备文件打开方法为logger_open：
* logger_open - the log's open() file operation
* note how near a no-op this is in the write-only case. keep it that way!
logger_open(struct
inode *inode,struct
file*file)
logger_log*log;
= nonseekable_open(inode,
file);
log
= get_log_from_minor(minor(inode->i_rdev));
if(!log)
return-enodev;
if(file->f_mode&
fmode_read){
logger_reader*reader;
reader
= kmalloc(sizeof(struct
logger_reader), gfp_kernel);
if(!reader)
return-enomem;
reader->log=
log;
init_list_head(&reader->list);
reader->r_off=
log->head;
list_add_tail(&reader->list,&log->readers);
file->private_data=
reader;
}else
新打开日志设备文件时，是从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的函数实现如下：
* get_entry_len - grabs the length of the payload of the next entry starting
* from 'off'.
* caller needs to hold log->mutex.
__u32 get_entry_len(struct
logger_log *log,
size_t off)
__u16 val;
switch(log->size-
off){
case1:
memcpy(&val,
log->buffer+
off,1);
memcpy(((char*)&val)+1,
log->buffer,1);
break;
default:
off,2);
returnsizeof(struct
logger_entry)+
val;
上面提到，每一条日志记录是由两大部分组成的，一个用于描述这条日志记录的结构体struct
logger_entry，另一个是记录体本身，即有效负载。结构体structlogger_entry的长度是固定的，只要知道有效负载的长度，就可以知道整条日志记录的长度了。而有效负载的长度是记录在结构体struct logger_entry的成员变量len中，而len成员变量的地址与struct
logger_entry的地址相同，因此，只需要读取记录的开始位置的两个字节就可以了。
又由于日志记录缓冲区是循环使用的，这两个节字有可能是第一个字节存放在缓冲区最后一个字节，而第二个字节存放在缓冲区的第一个节，除此之外，这两个字节都是连在一起的。因此，分两种情况来考虑，对于前者，分别通过读取缓冲区最后一个字节和第一个字节来得到日志记录的有效负载长度到本地变量val中，对于后者，直接读取连续两个字节的值到本地变量val中。
这两种情况是通过判断日志缓冲区的大小和要读取的日志记录在缓冲区中的位置的差值来区别的，如果相差1，就说明是前一种情况了。
最后，把有效负载的长度val加上struct logger_entry的长度就得到了要读取的日志记录的总长度了。
接下来，得到了要读取的记录的长度，就调用do_read_log_to_user函数来执行真正的读取动作：
ssize_t do_read_log_to_user(struct
struct
logger_reader*reader,
char
size_t count)
size_t len;
* we read from the log in two disjoint operations. first, we read from
* the current read head offset up to 'count' bytes or to the end of
* the log, whichever comes first.
*/
len
= min(count,
log->size-
if(copy_to_user(buf,
reader->r_off,
len))
return-efault;
* second, we read any remaining bytes, starting back at the head of
* the log.
if(count!=
len)
if(copy_to_user(buf+
len, log->buffer,
count - len))
return-efault;
reader->r_off=
logger_offset(reader->r_off+
count);
count;
这个函数简单地调用copy_to_user函数来把位于内核空间的日志缓冲区指定的内容拷贝到用户空间的内存缓冲区就可以了，同时，把当前读取日志进程的上下文信息中的读偏移r_off前进到下一条日志记录的开始的位置上。
logger.c文件，注册的写入日志设备文件的方法为logger_aio_write：
* logger_aio_write - our write method, implementing support for write(),
* writev(), and aio_write(). writes are our fast path, and we try to optimize
* them above all else.
ssize_t logger_aio_write(struct
kiocb *iocb,conststruct
iovec*iov,
unsignedlong
nr_segs, loff_t ppos)
file_get_log(iocb->ki_filp);
size_t orig
= log->w_off;
logger_entry header;
timespec now;
ssize_t ret
=0;
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);
null writes succeed, return zero */
if(unlikely(!header.len))
return0;
* fix up any readers, pulling them forward to the first readable
* entry after (what will be) the new write offset. we do this now
* because if we partially fail, we can end up with clobbered log
* entries that encroach on readable buffer.
fix_up_readers(log,sizeof(struct
header.len);
do_write_log(log,&header,sizeof(struct
logger_entry));
while(nr_segs-->0){
size_t len;
ssize_t nr;
figure out how much of this vector we can keep */
len
= min_t(size_t,
iov->iov_len,
header.len-
write out this segment's payload */
nr
= do_write_log_from_user(log,
iov->iov_base,
len);
if(unlikely(nr<0)){
log->w_off=
orig;
mutex_unlock(&log->mutex);
return
nr;
iov++;
+= nr;
wake up any blocked readers */
wake_up_interruptible(&log->wq);
输入的参数iocb表示io上下文，iov表示要写入的内容，长度为nr_segs，表示有nr_segs个段的内容要写入。我们知道，每个要写入的日志的结构形式为：
struct logger_entry | priority | tag | msg
其中， priority、tag和msg这三个段的内容是由iov参数从用户空间传递下来的，分别对应iov里面的三个元素。而logger_entry是由内核空间来构造的：
struct logger_entry header;
structtimespec 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结构体写入到日志缓冲区中：
* do_write_log - writes 'len' bytes from 'buf' to 'log'
* the caller needs to hold log->mutex.
staticvoid
do_write_log(struct
logger_log *log,constvoid*buf,
size_t count)
log->w_off);
memcpy(log->buffer+
log->w_off,
buf, len);
memcpy(log->buffer,
buf + len,
count - len);
log->w_off=
logger_offset(log->w_off+
由于logger_entry是内核堆栈空间分配的，直接用memcpy拷贝就可以了。
接着，通过一个while循环把iov的内容写入到日志缓冲区中，也就是日志的优先级别priority、日志tag和日志主体msg：
while(nr_segs-->0){
由于iov的内容是由用户空间传下来的，需要调用do_write_log_from_user来写入：
ssize_t do_write_log_from_user(struct
constvoid
if(len&&
copy_from_user(log->buffer+
buf, len))
if(copy_from_user(log->buffer,
并且在这里，还有一个重要的步骤：
* fix up any readers, pulling them forward to the first readable
* entry after (what will be) the new write offset. we do this now
* because if we partially fail, we can end up with clobbered log
* entries that encroach on readable buffer.
fix_up_readers(log,sizeof(struct
为什么要调用fix_up_reader这个函数呢？这个函数又是作什么用的呢？这是由于日志缓冲区是循环使用的，即旧的日志记录如果没有及时读取，而缓冲区的内容又已经用完时，就需要覆盖旧的记录来容纳新的记录。而这部分将要被覆盖的内容，有可能是某些reader的下一次要读取的日志所在的位置，以及为新的reader准备的日志开始读取位置head所在的位置。因此，需要调整这些位置，使它们能够指向一个新的有效的位置。我们来看一下fix_up_reader函数的实现：
* fix_up_readers - walk the list of all readers and "fix up" any who were
* lapped by the writer; also do the same for the default "start head".
* we do this by "pulling forward" the readers and start head to the first
* entry after the new write head.
fix_up_readers(struct
size_t len)
size_t old
size_t new
= logger_offset(old+
if(clock_interval(old,
new, log->head))
log->head=
get_next_entry(log,
log->head,
list_for_each_entry(reader,&log->readers,
list)
if(clock_interval(old,
new, reader->r_off))
reader->r_off=
判断log->head和所有读者reader的当前读偏移reader->r_off是否在被覆盖的区域内，如果是，就需要调用get_next_entry来取得下一个有效的记录的起始位置来调整当前位置：
* get_next_entry - return the offset of the first valid entry at least 'len'
* bytes after 'off'.
* caller must hold log->mutex.
size_t get_next_entry(struct
size_t off, size_t len)
size_t count
do{
size_t nr
off);
off
= logger_offset(off+
nr);
count
}while(count<
off;
而判断log->head和所有读者reader的当前读偏移reader->r_off是否在被覆盖的区域内，是通过clock_interval函数来实现的：
* clock_interval - is a < c < b in mod-space? put another way, does the line
* from a to b cross c?
inline int clock_interval(size_t
a, size_t b,
size_t c)
if(b<
a){
if(a<
c|| b>=
c)
return1;
}else{
c&& b>=
最后，日志写入完毕，还需要唤醒正在等待新日志的reader进程:
/* wake up any blocked readers */
wake_up_interruptible(&log->wq);
至此，logger驱动程序的主要逻辑就分析完成了，还有其它的一些接口，如logger_poll、 logger_ioctl和logger_release函数，比较简单，就不再分析了。
还有一点需要注意的是，由于logger驱动程序模块在退出系统时，是不会卸载的，所以这个模块没有module_exit函数，而对于模块里面定义的对象，也没有用对引用计数技术。