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的应用中众多的监听对象对事件驱动机制貌似诠释的有点忒多了点。