2012年7月第4周
linux inotify:
inotify 接口 -----监视文件系统事件， 可以用来监视单个文件或者一个目录(该目录本身或者目录中的文件 )所发生的事件，
相比于select 或 poll 等系统调用接口，事件可以更加细粒度的来进行监视。 相关的API接口:
int inotify_init(void); /* Create an initialized inotify instance */
inotify_add_watch(int fd, const char * pathname, uint32_t mask) /* add a watch to an initialized inotify instance */
inotify_rm_watch(int fd , int wd) /* remove an existing watch from an inotify instance */
struct inotify_event {
int wd; /* Watch descriptor (/
uint32_t mask; /* Mask of events */
uint32_ cookie;
uint32_t len;
char name[]
};
read(fd, buf, BUF_LEN); /* fd 是inotify_init() 返回的用于监视对象的文件描述符 , buf是一个指向 "inotify_event"结构数组的指针，
BUF_LEN 是以字节为单位的数组长度， 该函数会返回尽可能多的inotify_event, */
close(fd ) /* 关闭监视对象 */
android ram console
Ram console 类似于普通的串口console, printk()的内部实现都是向已注册和打开的console输出信息的，console可以基于串口实现，
当然也可以基于内存实现，区别是数据流的流向。ram console的实现中会生成proc/last_kmsg 的文件，该文件一般用于调试目的，如
出现系统出现panic重启后(内存只要不掉电，其保存的信息就不会丢失)，该文件可以保留现场。
1>在系统初始化时，预先保留一块物理内存用于保存Ram console打印的信息，并将申请保留的物理内存地址和大小保存在平台设备的
一个资源中。
2> Ram console模块会实现一个平台驱动用来匹配第一步注册的平台设备，在驱动的probe函数中，通过ioremap将保留的物理内存映射到
内核的地址空间中(代码是不会直接访问物理内存的，必须得经过页表的转换)，然后对这块物理内存中的信息进行分析，(这块保留的物理内存
可以分为两个部分，最开始的一部分用于保存描述该内存块的一个数据结构，char data[0]字段用于指明数据的起始位置，将数据数据中的size字段
与整个保留的物理内存加以比较以确定数据的有效性)以确定是否需要将里面的信息复制到另一个内存块里面(文件/proc/last_kmsg保存的信息)，
然后初始化这块保留物理内存相对应的管理数据结构(struct ram_console)中的字段(start,size)为0(相对应的变量是驻留在保留内存的最开始的地方，
类似于内存管理中内部slab描述符)，在console的写操作中会根据该数据结构中的start字段来确定写入的位置。
参照ram console的机制， 可以仿照保留一块物理内存用于存放特定的信息，如要分析系统中分配页面大于8k的模块，我们可以在内存分配的核心函数中
通过trace_printk (利用__builtin_return_address机制来追溯调用链)向ftrace缓冲中保存信息，当系统由于内存分配失败而出现ipanic时， 内核里面有个ipanic
事件的通知链机制，当系统出现ipanic的时候，会调用注册在该链表结点的回调函数，ftrace模块就注册了这样的一个结点，在回调函数中，通过一个开关(
/proc/sys/kernel/ftrace_dump_on_oops)来确定是否将ftrace的缓冲区的信息打印出来，是通过printk来打印的，可以扩展下将信息输出到我们保留的物理内存
中(必须得实现相应的写入接口)
事件驱动机制：
从最近的写代码，看代码中发现，不管是内核代码，应用代码(c, android app), 事件驱动运用的比较广泛， 内核里有通知链的机制来监听感兴趣的事件，
应用程序中的select, poll, inotify机制应该也都属于事件驱动的一个子集， android的应用中众多的监听对象对事件驱动机制貌似诠释的有点忒多了点。